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Preface 


This  document  is  one  of  a  series  of  publications  of  the  Software  Engineering  Institute  at 
Carnegie  Mellon  University  called  security  improvement  modules.  They  are  intended  to 
provide  practical  guidance  to  help  organizations  improve  the  security  of  their  networked 
computer  systems. 

Module  structure 

Each  module  addresses  an  important  but  relatively  narrowly  defined  problem  in  network 
and  system  security.  The  first  section  of  the  module  describes  the  problem  and  outlines  a 
set  of  security  improvement  practices  to  help  solve  it.  Each  practice  is  a  recommended 
way  of  performing  common  tasks  related  to  the  secure  operation  of  networked  computer 
systems. 

The  remaining  sections  of  the  module  are  detailed  descriptions  of  the  practices.  Each 
includes  a  rationale  for  the  recommended  actions  and  a  description  of  how  to  perform 
them. 

Intended  audience 

The  practices  are  primarily  written  for  system  and  network  administrators  whose  day-to- 
day  activities  include  installation,  configuration,  and  maintenance  of  the  computers  and 
networks.  Occasionally,  practices  are  written  to  assist  the  managers  responsible  for 
network  and  system  administration. 

Revised  versions 

Network  and  system  technologies  continue  to  evolve  rapidly,  leading  to  new  security 
problems  and  solutions.  Modules  and  practices  need  to  be  revised  occasionally,  so  to 
permit  more  timely  publication  of  new  versions,  we  also  publish  them  on  the  World  Wide 
Web.  At  the  end  of  each  section  of  this  document  is  the  URL  of  its  Web  version. 

Implementation  details 

How  an  organization  adopts  and  implements  the  practices  often  depends  on  the 
networking  and  computing  technologies  it  uses.  For  some  practices,  technology-specific 
implementation  details  are  published  on  the  World  Wide  Web.  The  Web  version  of  each 
practice  contains  links  to  the  implementation  details. 
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Securing  Network  Servers 


A  note  on  terminology 


The  development  of  computer  networks  has  resulted  in  an  important  class  of  computers: 
network  servers.  The  primary  purpose  of  these  machines  is  to  provide  services,  including 
both  computational  and  data  services,  to  other  computers  on  the  network. 

Because  of  their  service  role,  it  is  common  for  servers  to  store  many  of  an  organization’s 
most  valuable  and  confidential  information  resources.  They  also  are  often  deployed  to 
provide  a  centralized  capability  for  an  entire  organization,  such  as  communication 
(electronic  mail)  or  user  authentication.  Security  breaches  on  a  network  server  can  result 
in  the  disclosure  of  critical  information  or  the  loss  of  a  capability  that  can  affect  the  entire 
organization.  Therefore,  securing  network  servers  should  be  a  significant  part  of  your 
network  and  information  security  strategy. 

Many  security  problems  can  be  avoided  if  servers  and  networks  are  appropriately 
configured.  Default  hardware  and  software  configurations  are  typically  set  by  vendors  to 
emphasize  features  and  functions  more  than  security.  Since  vendors  are  not  aware  of  your 
security  needs,  you  must  configure  new  servers  to  reflect  your  security  requirements  and 
reconfigure  them  as  your  requirements  change. 

The  practices  recommended  here  are  designed  to  help  you  configure  and  deploy  network 
servers  that  satisfy  your  organization’s  security  requirements.  The  practices  may  also  be 
useful  in  examining  the  configuration  of  previously  deployed  servers. 


The  term  “server”  is  used  in  this  module  to  mean  the  combination  of  the  hardware, 
operating  system,  network  service,  application  software,  and  network  connection.  When  it 
is  necessary  to  be  more  specific,  we  explicitly  mention  one  of  these  five  components. 

Although  this  module  focuses  on  securing  network  servers,  many  of  the  practices  are  also 
applicable  to  securing  workstations  or  other  computers  on  your  network.  To  make  it  easier 
for  these  practices  to  appear  in  other  modules,  we  use  the  word  “computer”  to  mean 
workstations,  servers,  or  other  computers.  At  times,  we  differentiate  between  guidance  for 
workstations  and  guidance  for  network  servers. 


CMU/SEI-SIM-010 


1 


Who  should  read  these 
practices 


What  these  practices  do 
not  cover 


These  practices  are  applicable  to  your  organization  if 

•  you  operate  or  plan  to  operate  a  networked  system  of  workstations  that  depend  on 
servers  for  information  or  computation  services 

•  you  operate  or  plan  to  operate  a  public  network  server  (such  as  a  public  Web  site) 
connected  to  an  external  network  (such  as  the  Internet) 

We  assume  that  you  have  the  following  security  requirements  for  information  resources 

stored  on  these  servers: 

•  Some  or  all  of  the  information  is  sensitive  or  proprietary.  Access  must  be  limited  to 
authorized  and  properly  authenticated  users  (inside  or  outside  of  your  organization). 

•  The  integrity  of  this  information  is  critical.  It  must  not  be  compromised;  that  is,  not 
modified  by  unauthorized  users  or  processes  operating  on  their  behalf. 

•  That  information  must  be  readily  accessible  by  authorized  users  whenever  they  need  it 
in  the  course  of  their  work. 

We  assume  that  you  have  these  security  requirements  for  the  services  provided  by  those 

servers: 

•  Only  authorized  and  properly  authenticated  users  may  use  these  services. 

•  Users  must  be  able  to  access  these  services  quickly. 


These  practices  help  you  appropriately  configure  a  network  server  and  its  operating 
system  when  it  is  first  deployed.  They  do  not  attempt  to  address  security  issues  for 

•  the  particular  network  service  that  will  be  provided  by  a  server.  We  expect  to  address 
specifics  of  major  network  services  in  other  modules.  See,  for  example,  the  modules 
Securing  Public  Web  Servers  [Kossakowski  00]  and  Deploying  Firewalls  [Fithcn  99]. 

•  the  network  to  which  the  server  is  attached 

•  day-to-day  operations  of  servers.  We  address  operations  in  other  modules;  for  example, 
activities  related  to  detecting  signs  of  intrusion  are  covered  in  the  modules  Preparing 
to  Detect  Signs  of  Intrusion  [Kochmar  98]  and  Detecting  Signs  of  Intrusion  [Firth  97]. 

•  desktop  machines  that  may  provide  some  kind  of  network  service  but  are  used 
primarily  as  workstations.  Workstation  security  is  addressed  in  the  module  Securing 
Desktop  Workstations  [Simmel  99]. 

•  security  of  network  services  provided  by  third  parties  under  contract  with  your 
organization.  See  the  module  Security  of  Information  Technology  Service  Contracts 
[Allen  98]. 

•  security  considerations  related  to  any  service  client  software 

•  wireless  networking  and  its  relationship  to  securing  network  servers 

We  assume  that  the  reader  is  capable  of  performing  the  initial  setup  of  the  computer: 
unpacking  it,  confirming  the  hardware  configuration,  installing  the  default  operating 
system,  and  attaching  the  network  connection,  so  we  do  not  explicitly  cover  those  aspects 
of  configuring  a  network  server.  We  note,  however,  that  some  of  the  practices  are  most 
effective  if  performed  during  the  process  of  installing  the  operating  system. 

These  practices  do  not  address  server  physical  security  in  detail  (such  as  protection  from 
theft  and  natural  disasters). 
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Security  issues 


There  are  four  major  security  issues  related  to  network  servers: 


1 .  Confidentiality  —  Maintaining  the  confidentiality  of  information  stored  on  the  server. 
This  includes 

•  ensuring  that  only  authorized  users  can  access  the  services  and  information 

•  ensuring  that  authorized  users  can  access  only  the  services  for  which  they  are 
authorized 

2.  Integrity  —  Maintaining  the  integrity  of  information  stored  on  the  servers.  This 
includes  ensuring  that  you  can  recognize  and  recover  from  breaches  of  integrity. 

3.  Availability  —  Maintaining  the  availability  of  the  services.  This  includes 

•  ensuring  that  services  are  uninterrupted  even  when  there  are  hardware  or  software 
failures  or  during  routine  system  maintenance 

•  ensuring  that  you  can  recognize  and  recover  from  security  incidents  in  a  timely 
manner 

4.  Mutual  Authentication  —  Ensuring  that  the  user  is  who  he  claims  to  be  and  that  the 
network  server  host  is  who  it  claims  to  be. 

The  common  security  requirements  of  confidentiality,  integrity,  and  availability,  described 
above,  can  be  especially  critical  for  network  servers.  For  example: 

•  File  servers  and  database  servers  are  often  used  to  store  your  organization’s  most 
important  information  resources,  which  must  be  kept  strictly  confidential.  Servers  may 
also  store  information  used  for  management  decisions  or  customer  billing,  which 
demands  a  high  level  of  integrity. 

•  Authentication  servers  store  information  about  user  accounts  and  passwords;  any 
disclosure  could  compromise  all  the  information  on  all  of  the  hosts  in  your  network. 

•  Public  servers  (such  as  Web  servers)  can  be  a  major  component  in  the  strategy  your 
organization  uses  to  represent  itself  to  the  public,  so  the  integrity  of  the  information  on 
those  servers  is  critically  important. 

•  Servers  used  by  customers  for  electronic  commerce  must  be  available  and  reliable  to 
prevent  loss  of  revenue. 

•  Servers  that  provide  essential  services  for  employees  of  your  organization  must  be 
reliably  available;  otherwise  people  may  be  unable  to  work. 

With  respect  to  mutual  authentication,  user  identities  (id,  password)  can  be  easily  captured 
with  network  sniffers  when  passed  in  clear  text.  These  identities  can  then  be  used  by 
intruders  to  compromise  your  servers.  Network  server  host  identities  can  be  redirected 
through  IP  (Internet  protocol)  and  DNS  (Domain  Name  System)  spoofing,  resulting  in 
intruders  presenting  their  servers  to  legitimate  users  as  though  they  were  those  belonging 
to  your  organization. 

There  are  other  aspects  of  network  servers  that  can  make  them  tempting  targets  for 
intruders: 

•  Public  servers  often  have  publicly  known  host  names  and  IP  addresses. 

•  Public  servers  may  be  deployed  outside  an  organization’s  firewall  or  other  perimeter 
defenses. 

•  Servers  usually  actively  listen  for  requests  for  services  on  known  ports,  and  they  try  to 
process  such  requests. 
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•  Servers  often  do  not  have  an  attending  administrative  user  who  notices  signs  of 
unusual  activity. 

•  Servers  are  often  remotely  administered,  so  they  willingly  accept  connections  from 
privileged  accounts. 

•  Servers  often  are  configured  to  reboot  automatically  after  some  kinds  of  failures,  which 
can  offer  opportunities  for  intruders. 


Security  improvement  To  secure  a  network  server,  we  recommend  a  three-part  approach.  It  requires 

approach  implementing  security  practices  in  these  areas: 

1 .  planning  and  executing  the  deployment  of  servers 

2.  configuring  servers  to  help  make  them  less  vulnerable  to  attack 

3.  maintaining  the  integrity  of  the  deployed  servers 

The  practices  are  designed  to  improve  security  in  two  major  ways: 

•  They  help  to  maximize  security  on  each  network  server  host,  which  provides  a  backup 
in  case  of  failure  of  perimeter  defenses.  Host  security  is  also  a  first-line  of  defense 
against  internal  threats,  which  generally  have  a  higher  probability  of  occurrence  than 
external  threats. 

•  They  prepare  you  to  better  recognize  and  recover  from  security  breaches. 


Summary  of 
recommended  practices 


Area 

Recommended  Practice 

Planning 

deployment 

1.  Develop  a  computer  deployment  plan  that  includes  security 
issues. 

2.  Include  explicit  security  requirements  when  selecting  servers. 

Configuring 

servers 

3.  Keep  operating  systems  and  applications  software  up  to  date. 

4.  Offer  only  essential  network  services  and  operating  system 
services  on  the  server  host  machine. 

5.  Configure  computers  for  user  authentication. 

6.  Configure  computer  operating  systems  with  appropriate  object, 
device,  and  file  access  controls. 

7.  Identify  and  enable  system  and  network  logging  mechanisms. 

8.  Configure  computers  for  file  backups.  j 

Maintaining 
server  integrity 

9.  Protect  computers  from  viruses  and  similar  programmed 
threats. 

10.  Configure  computers  for  secure  remote  administration. 

11.  Allow  only  appropriate  physical  access  to  computers. 

Abbreviations  used  in 

ACL 

access  control  list 

these  practices 

DNS 

Domain  Name  Service 

FTP 

File  Transfer  Protocol 

HTTP 

HyperText  Transfer  Protocol 

IP 

Internet  Protocol 

IPX 

Internetwork  Packet  Exchange 

LAN 

local  area  network 
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The  latest  version  of  this  module  is  available  on  the  Web  at  URL 

http://www.cert.org/security-improvement/modules/mlO.html 
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Develop  a  computer  deployment  plan  that  includes 
security  issues. 


Why  this  is  important 


How  to  do  it 


Most  deployment  plans  address  the  cost  of  the  computers,  schedules  to  minimize  work 
disruption,  installation  of  applications  software,  and  user  training.  In  addition,  you  need  to 
include  a  discussion  of  security  issues. 


You  can  eliminate  many  networked  systems  vulnerabilities  and  prevent  many  security 
problems  if  you  securely  configure  computers  and  networks  before  you  deploy  them. 
Vendors  typically  set  computer  defaults  to  maximize  available  functions,  so  you  usually 
need  to  change  defaults  to  meet  your  organization’s  security  requirements. 

You  are  more  likely  to  make  decisions  about  configuring  computers  appropriately  and 
consistently  when  you  use  a  detailed,  well-designed  deployment  plan.  Developing  such  a 
plan  will  support  you  in  making  some  of  the  hard  trade-off  decisions  between  usability 
and  security. 

Consistency  is  a  key  factor  in  security,  because  it  fosters  predictable  behavior.  This  will 
make  it  easier  for  you  to  maintain  secure  configurations  and  help  you  to  identify  security 
problems  (which  often  manifest  themselves  as  deviations  from  predictable,  expected 
behavior).  Refer  to  the  practice,  “Keep  operating  systems  and  applications  software  up  to 
date.” 


Make  the  decisions  described  below  and  then  record  them. 

Note:  We  assume  that  you  are  deploying  workstations  and  servers  in  an  existing 
infrastructure,  which  includes  an  existing  network.  The  security  issues  related  to  the 
network  architecture,  including  where  you  place  servers  and  workstations  on  the  network, 
are  outside  the  scope  of  this  practice.  As  a  general  rule,  subnets  with  differing  security 
policies  require  some  form  of  network  separation  such  as  firewalls  (refer  to  Deploying 
Firewalls  [Fithen  99]). 

>*  Identify  the  purpose  of  each  computer. 

Document  how  the  computer  will  be  used.  Consider  the  following: 

•  What  categories  of  information  will  be  stored  on  the  computer? 

•  What  categories  of  information  will  be  processed  on  the  computer  (but  retrieved  from 
and  stored  on  another  computer)? 

•  What  are  the  security  requirements  for  that  information? 
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•  What  network  service(s)  will  be  provided  by  the  computer? 

•  What  are  the  security  requirements  for  those  services? 

>  Identify'  the  network  services  that  will  he  provided  on  the  computer 

The  network  services  you  list  in  your  deployment  plan  may  include  electronic  mail,  access 
to  the  Web,  domain  name  services,  file  transfers,  and  access  to  corporate  databases.  For 
each  service,  document  whether  the  computer  will  be  configured  as  a  client,  a  server,  or 
both  (such  as  in  the  case  of  file  and  printer  sharing). 

Clients:  Workstations  are  normally  configured  as  clients  for  several  network  services.  You 
should  document  the  planned  behavior  of  those  clients:  the  levels  of  access  required,  the 
type  of  access  (read,  write,  etc.),  and  other  aspects  of  the  configurations  required  for  client 
software. 

Servers:  As  a  general  rule,  a  network  server  should  be  dedicated  to  a  single  service.  This 
usually  simplifies  the  configuration,  which  reduces  the  likelihood  of  configuration  errors. 
It  also  can  eliminate  unexpected  and  unsafe  interactions  among  the  services  that  present 
opportunities  for  intruders. 

In  some  cases,  it  may  be  appropriate  to  offer  more  than  one  service  on  a  single  host 
computer.  For  example,  the  server  software  from  many  vendors  combines  the  file  transfer 
protocol  (FTP)  and  the  hypertext  transfer  protocol  (HTTP)  services  in  a  single  package. 
For  some  organizations,  it  may  be  appropriate  to  provide  access  to  public  information  via 
both  protocols  from  the  same  server  host  but  we  do  not  recommend  this  as  it  is  a  less 
secure  configuration. 


>  Identify :  the  network  service  software,  both  client  and  server,  to  be  installed  on  the 
computer 

Many  operating  system  vendors  bundle  network  service  software  for  both  clients  and 
servers.  You  may  choose  to  use  those  packages.  For  major  services,  however,  third  party 
vendors  may  provide  products  that  offer  much  better  security.  When  making  your  choice, 
pay  special  attention  to  the  ability  of  candidate  packages  to  meet  your  security 
requirements,  and  document  your  selection. 

Identify  other  application  or  utility  software  that  will  be  installed  on  the  computer.  Include 
not  only  user-oriented  application  software,  but  also  system-related  software  and  security  * 
related  software.  The  module  Preparing  to  Detect  Signs  of  Intrusion  [Kochmar  98] 
provides  details  on  selecting  some  kinds  of  security-related  software. 

>  Identify •  the  users  or  categories  of  users  of  the  computer 

For  workstations,  you  will  sometimes  be  able  to  identify  an  individual  who  will  be  the 
primary  user;  but  more  often,  you  will  have  to  define  categories  of  users.  The  categories 
are  based  on  user  roles  that  reflect  their  authorized  activity.  The  roles  are  often  based  on 
similar  work  assignments  and  similar  needs  for  access  to  particular  information 
resources — system  administrators,  software  developers,  data  entry  personnel,  etc.  If 
appropriate,  include  categories  of  remote  users  and  temporary  or  guest  users. 

For  network  servers,  document  the  categories  of  users  that  will  be  allowed  access  to  the 
provided  services.  For  public  servers  connected  to  the  Internet,  the  category  of  users  is 
probably  everyone.  For  internal  servers,  you  may  need  to  categorize  users  by  their 
organizational  department,  physical  location,  or  job  responsibilities.  You  also  need  a 
category  of  administrative  users  who  will  need  access  to  administer  the  network  server 
and  possibly  another  category  for  backup  operators. 
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Normally,  access  to  network  servers  should  be  restricted  to  only  those  administrators 
responsible  for  operating  and  maintaining  the  server. 

In  general,  you  should  prevent  the  use  of  a  network  server  as  a  workstation.  This  will 
ensure  that  the  server’s  users  are  restricted  to  those  who  are  authorized  to  access  the 
provided  service  and  responsible  for  server  administration.  Correspondingly,  you  should 
prevent  having  network  services  reside  on  and  be  provided  by  a  user  workstation.  General 
users  are  typically  not  trained  in  network  service  administration. 

V  Determine  the  privileges  that  each  category '  of  user  will  have  on  the  computer. 

To  document  privileges,  create  a  matrix  that  shows  the  users  or  user  categories  (defined  in 
the  previous  step)  cross-listed  with  the  privileges  they  will  possess.  The  privileges  are 
customarily  placed  in  groups  that  define  what  system  resources  or  services  a  user  can  read, 
write,  change,  execute,  create,  delete,  install,  remove,  turn  on,  or  turn  off. 

V  Decide  how  users  will  be  authenticated  and  how  authentication  data  will  be  protected. 

For  workstations,  it  is  normal  to  authenticate  users  via  the  authentication  capability 
provided  with  the  operating  system. 

For  network  servers,  there  are  usually  two  kinds  of  authentication:  (1)  the  kind  provided 
with  the  operating  system,  commonly  used  for  authenticating  administrative  users  and  (2) 
the  kind  provided  by  the  network  service  software,  commonly  used  for  authenticating 
users  of  the  service.  A  particular  software  implementation  of  a  network  service  may  use 
the  provided  authentication  capability,  and  thus  it  may  be  necessary  for  users  of  that 
service  to  have  a  local  identity  (usually  a  local  account)  on  the  server. 

Authentication  mechanisms  can  be  both  procedural  and  technological.  The  most  common 
approach  is  the  use  of  passwords;  but  other  mechanisms  can  be  used,  such  as  keys,  tokens, 
and  biometric  devices  (devices  that  recognize  a  person  based  on  biological  characteristics 
such  as  fingerprints  or  patterns  of  the  retinal  blood  vessels). 

Because  authentication  mechanisms  like  passwords  require  information  to  be  accessible  to 
the  authentication  software,  carefully  document  how  that  information  will  be  protected. 
Authentication  data  is  critical  security  information  that  requires  a  high  level  of  protection. 

>*  Determine  how  appropriate  access  to  information  resources  will  be  enforced. 

For  many  resources,  such  as  program  and  data  files,  the  access  controls  provided  by  the 
operating  system  are  the  most  obvious  means  to  enforce  access  privileges.  Also,  consider 
using  encryption  technologies  to  protect  the  confidentiality  of  sensitive  information.  In 
some  cases,  protection  mechanisms  will  need  to  be  augmented  by  policies  that  guide 
user’s  behavior  related  to  their  workstations. 

See  also  the  practice  “Configure  computer  operating  systems  with  appropriate  object, 
device,  and  file  access  controls.” 

>  Develop  intrusion  detection  strategies  for  the  computer. 

Many  of  the  common  intrusion  detection  methods  depend  on  the  existence  of  various  logs 
that  your  systems  produce  and  on  the  availability  of  auditing  tools  that  analyze  those  logs. 
In  your  deployment  plan,  describe  the  kinds  of  information  that  will  be  collected  and 
managed  on  each  computer  in  support  of  security.  This  will  help  you  install  the 
appropriate  software  tools  and  configure  these  tools  and  the  operating  system  to  collect 
and  manage  the  necessary  information. 
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This  topic  is  elaborated  in  the  security  improvement  module  Preparing  to  Detect  Signs  of 
Intrusion  [Kochmar  98]. 

>  Document  procedures  for  backup  and  recovery  of  information  resources  stored  on  the 
computer. 

Possessing  recent,  secure  backup  copies  of  information  resources  makes  it  possible  for 
you  to  quickly  restore  the  integrity  and  availability  of  information  resources.  Successful 
restoration  depends  on  configuring  the  operating  system,  installing  appropriate  tools,  and 
following  defined  operating  procedures.  You  need  to  document  backup  procedures 
including  roles,  responsibilities,  and  how  the  physical  media  that  store  the  backup  data  arc 
handled,  stored,  and  managed.  Consider  using  encryption  technologies  to  protect  backups. 

Your  backup  procedures  need  to  account  for  the  possibility  that  backup  files  may  have 
been  compromised  by  an  undetected  intrusion.  Verify  the  integrity  of  all  backup  files  prior 
to  using  them  to  recover  systems.1 

For  some  network  servers,  such  as  those  providing  public  services  like  the  World  Wide 
Web,  it  is  common  to  develop  the  information  content  used  by  those  services  on  a 
different  host.  The  authoritative  version  of  this  content  is  maintained  (and  backed  up)  on 
this  second  computer,  and  then  transferred  to  the  public  server.  This  method  makes  it 
unnecessary  to  perform  file  backups  of  the  Web  page  content  itself.  If  the  information  is 
ever  compromised,  you  can  restore  it  by  transferring  a  copy  from  the  authoritative  version. 
However,  backups  of  Web  server  logs  are  still  required.  Backups  of  configuration  and 
installation  information  are  also  required  unless  you  have  a  configuration  management 
system  that  can  be  used  to  recover  or  rebuild  a  system  from  a  trusted  baseline. 

For  more  information,  refer  to  the  practice  “Configure  computers  for  file  backups.” 

>*  Determine  how  network  services  will  be  maintained  or  restored  after  various  kinds  of 
faults. 

To  maintain  the  availability  of  services  essential  to  your  business,  you  generally  need 
some  level  of  redundancy.  For  example,  you  may  want  to  specify  when  to  use  hot,  warm, 
and  cold  backups.  Hot  backups  provide  the  capability  to  immediately  switch 
configurations  because  the  backup  system  is  run  in  parallel  with  the  primary  system. 
Warm  backups  require  some  degree  of  reconfiguration  before  you  use  them  since  they  are 
not  run  in  full  parallel  with  operational  systems.  You  must  start  cold  backups  from  a 
shutdown  state  and  bring  them  up  to  date  before  using  them. 

Ensure,  as  part  of  your  plan,  that  no  single  failure  (power  supply,  hardware,  software,  etc.) 
will  make  an  essential  service  unavailable  for  a  period  of  time  you  consider  unacceptable. 

>  Develop  and  follow  a  documented  procedure  for  installing  an  operating  system. 

In  your  procedure,  include  steps  to  implement  all  the  decisions  you  made  in  the  steps 
above  and  describe  all  the  parameters  that  are  set  during  installation. 

In  many  cases,  the  parameters  are  recorded  in  scripts  or  configuration  files  that  are 
executed  or  read  during  various  phases  of  the  installation.  Make  all  your  parameter 
choices  explicit,  even  if  they  match  the  vendor’s  current  default  settings.  (This  may  seem 
to  be  unnecessary,  but  it  can  prevent  security  problems  if  you  subsequently  reuse  your 


1.  Refer  to  the  module  Responding  to  Intrusions  [Kossakowski  99],  specifically  the  practice 
“Return  systems  to  normal  operation,”  available  at  http://www.cert.org/security-improvement/ 
practices/p05 1  .html. 
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scripts  or  configuration  files  to  configure  workstations  and  servers.)  Your  explicit  choices 
will  still  be  used  even  if  the  vendor’s  defaults  have  changed  with  new  releases.  Your 
installation  procedure  should  also  specify  the  vendor’s  security-related  updates  or  patches 
that  are  to  be  applied  to  the  operating  system. 

If  possible,  have  a  single  person  perform  the  installation  procedure  for  each  computer  and 
capture  each  installation  step  in  a  documented  manner  (such  as  through  using  a  checklist). 

Refer  to  the  implementation  “Installing  and  securing  Solaris  2.6  servers”2  and  the  Solaris 
Security  Step-By-Step  Guide  Version  1.0  [SANS  99]  for  guidance  on  securing  Solaris 
servers. 

Determine  how  the  computer  will  be  connected  to  your  network. 

There  are  concerns  relating  to  network  connections  that  can  affect  the  configuration  and 
use  of  any  one  computer. 

LANs:  Many  organizations  use  a  broadcast  technology  such  as  Ethernet  for  their  local 
area  networks.  In  these  cases,  information  traversing  a  network  segment  can  be  seen  by 
any  computer  on  that  segment.  This  suggests  that  you  should  only  place  “trusted” 
computers  on  the  same  network  segment,  or  else  encrypt  information  before  transmitting 
it.3 

Modems:  Modems  permit  direct  connectivity  between  one  of  your  computers  (and  thus, 
potentially,  your  internal  network)  and  the  external  networks  reachable  by  the  public 
telephone  network.  Many  organizations  forbid  users  to  attach  a  modem  to  a  workstation. 
We  recommend  that  you  do  not  allow  users  to  attach  a  modem  to  their  workstation  any 
time  it  is  connected  to  your  internal  network. 

It  is  also  important  to  document  the  use  of  modems  on  a  network  server.  As  a  general  rule, 
do  not  attach  modems  to  any  servers  other  than  servers  whose  purpose  is  to  provide  dial-in 
access.  Some  vendors  may  require  direct  modem  access  to  provide  some  level  of  service. 
In  this  case,  we  recommend  establishing  procedures  to  enable  the  vendor  to  access  the 
server  via  modem,  and  disconnecting  the  modem  when  it  is  not  in  use.  You  should  require 
strong  user  authentication  methods  such  as  one-time  passwords  or  token-based  systems 
for  this  type  of  access. 

>  Identify  the  security  concerns  related  to  day-to-day  administration  of  the  computer. 

If  your  organization  is  small,  it  may  be  feasible  to  administer  both  workstations  and 
network  servers  individually  from  their  consoles.  We  recommend  this  method  because  it  is 
the  most  secure. 

In  most  cases,  however,  workstations  and  servers  are  some  distance  from  the  offices  of  the 
system  administrators.  As  a  result,  a  significant  amount  of  day-to-day  administration  is 
done  from  the  administrator’s  workstation  via  the  network. 


2.  Available  at  http://www.cert.org/security-improvement/implementations/i0027.02.html  in  April 
2000. 

3.  However,  note  that  most  commonly  used  network  protocols  based  on  TCP/IP  require  at  least  part 
of  the  information  in  a  packet  (source,  destination,  port)  to  be  unencrypted,  which  exposes  the 
network  to  traffic  analysis  by  a  sniffer.  By  using  specific  protocols,  such  as  IPSEC  in  tunneling 
mode,  you  can  further  reduce  the  amount  of  cleartext  information  thereby  reducing  the  potential 
for  traffic  analysis. 
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Providing  the  means  for  secure  remote  administration4  typically  requires  configuring  the 
operating  system  and  installing  various  software  tools.  This  could  include  configuring  the 
tools  to  encrypt  administration  commands  and  data  that  traverse  the  network  between  the 
target  computer  and  the  administrator’s  workstation.  You  need  to  define  and  document 
your  administration  procedures  to  configure  the  computer  appropriately. 

>-  Identify  actions  to  protect  information  contained  on  hardware  that  is  no  longer  in  use . 

Determine  the  steps  you  need  to  take  to  ensure  that  the  information  contained  on  hardware 
being  updated,  replaced,  removed  from  service,  or  disposed  of  is  eliminated  (as  much  as 
possible).  For  example,  erase  and  reformat  disks,  rewrite  tapes,  and  clear  firmware 
passwords.  The  extent  of  your  actions  is  dependent  upon  the  sensitivity  of  the  information. 
You  may  need  to  physically  destroy  hardware  containing  highly  sensitive  information  to 
ensure  that  the  hardware  cannot  be  used  and  that  the  information  cannot  be  accessed. 

>  Keep  your  computer  deployment  plan  current . 

You  need  to  update  your  computer  deployment  plan  when  relevant  changes  occur.  Sources 
of  change  may  include  new  technologies,  new  security  threats,  updates  to  your  network 
architecture,  the  addition  of  new  classes  of  users  or  new  organizational  units,  etc. 

Policy  considerations  Your  organization’s  security  policy  for  networked  systems  should  require  that 

•  a  detailed  computer  deployment  plan  be  developed,  implemented,  and  maintained 
whenever  computers  are  being  deployed  (or  redeployed) 

•  access  to  your  deployment  plan  only  be  given  to  those  who  require  the  information  to 
perform  their  jobs 

•  all  new  and  updated  servers  be  installed,  configured,  and  tested  in  a  stand-alone  mode  or 
within  test  networks  (i.e.,  not  connected  to  operational  networks) 

•  all  servers  present  a  warning  banner  to  all  users  indicating  that  they  are  legally 
accountable  for  their  actions  and,  by  using  the  server,  they  are  consenting  to  having  their 
actions  logged. 

Where  to  find  updates  The  latest  version  of  this  practice,  plus  implementation  details  for  selected  technologies,  is 

available  on  the  Web  at  URL 

http://www.cert.org/security-improveinent/practices/p065.htm] 


2  Include  explicit  security  requirements  when  selecting 

servers. 


It  is  common  to  consider  factors  such  as  functionality,  price,  performance,  and  capacity 
when  selecting  computing  technology.  When  you  specify  the  requirements  for  selecting 
servers  for  your  organization  (including  the  host  machine  hardware,  operating  system,  and 
server  software),  you  should  also  include  security  requirements. 


Why  this  is  important  There  are  many  server  vendors,  and  the  security  capabilities  of  their  products  vary.  Many 

of  the  known  and  frequently  exploited  network  server  vulnerabilities  apply  only  to  certain 
products  and  platforms.  If  you  consider  security  requirements  when  selecting  servers,  you 
may  be  able  to  choose  products  with  fewer  vulnerabilities  or  select  better  security-related 
features,  which  can  result  in  a  substantially  more  secure  site.  This  makes  the  long-term 
operation  of  your  site  more  economical  because  you  can  reduce  the  costs  associated  with 
administration  tasks  (such  as  patching  systems)  as  well  reduce  costs  caused  by  intrusions 
and  their  effects. 


Background  information  The  selection  of  server  products  requires  you  to  make  trade-offs  among  competing 

requirements.  To  do  this,  you  must  first  understand  your  organization’s  requirements. 

For  a  general-purpose  server,  important  performance  requirements  include  response  time 
(typically  measured  in  terms  of  the  number  of  connections  per  second  that  the  server  will 
allow)  and  throughput  (typically  measured  in  terms  of  the  number  of  service  responses 
that  can  be  delivered  to  the  network). 

Typical  functionality  requirements  include  the  ability  to  provide  a  range  of  services  (such 
as  Web,  email,  DNS,  FTP,  database  access)  and  the  ability  to  receive  and  process  user 
information  (such  as  authentication  and  access  control).  In  addition,  you  will  likely  want 
the  ability  to  administer  the  server  software  and  the  host  system  from  another  host  on  your 
network  and,  perhaps,  remotely  from  outside  of  your  internal  network. 

Availability  of  experienced  staff  to  administer  your  server  and  server  products  is  a  critical 
factor  to  consider  in  server  selection.  It  is  generally  preferable  to  have  capable, 
knowledgeable  administrators  working  in  a  less  secure,  but  known,  server  environment 
than  to  have  to  train  current  staff  in  the  use  of  a  more  secure,  but  unknown,  server 
environment  —  unless,  of  course,  you  plan  to  make  a  longer  term  investment  in  the 
technology  of  the  unknown  environment. 

Security  requirements  typically  include  the  following: 

•  the  absence  of  vulnerabilities  used  by  known  forms  of  attack  against  server  hosts 

•  the  ability  to  restrict  administrative  activities  to  authorized  users  only 
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•  the  ability  to  deny  access  to  information  on  the  server  other  than  that  intended  to  be 
available 

•  the  ability  to  disable  unnecessary  network  services  that  may  be  built  into  the  operating 
system  or  server  software 

•  the  ability  to  control  access  to  various  forms  of  executable  programs  (such  as  CGI 
scripts  and  server  plug-ins  in  the  case  of  Web  servers) 

•  the  ability  to  log  appropriate  server  activities  for  purposes  of  detecting  intrusions  and 
attempted  intrusions 


How  to  do  it 


>  Identify'  your  functionality  and  performance  requirements. 

Document  the  operating  system  features  needed,  even  if  you  are  confined  to  using  one 
vendor’s  operating  system.  Include  the  requirements  for  both  general  security  features 
(such  as  capabilities  for  user  authentication  and  file  access  controls)  and  for  special 
security  features  (such  as  an  encrypting  file  system,  or  a  built-in  feature  to  erase  memory 
and  disk  blocks  before  reallocating  them). 

Document  the  applications  software  you  intend  to  run  on  the  server. 

Given  the  operating  system  and  applications  software  features,  document  the  needed 
hardware,  including  the  processor  architecture,  memory  requirements,  secondary  storage 
requirements  (such  as  hard  disk  drives  and  removable-medium  drives),  networking 
requirements  (such  as  modems  or  Network  Interface  cards),  and  console  requirements. 
Include  requirements  for  server  expansion  and  growth  (ensure  the  hardware  can 
accommodate  this). 

Document  the  hardware  configuration.  This  will  aid  you  in  selecting  and  securely 
configuring  the  software. 

>  Review  the  recommended  practices  that  address  the  configuration  and  operation  of  the 
server  product.  Note  the  kinds  of  security'  problems  that  those  practices  are  intended  to 
help  you  avoid . 

>  Where  available,  look  at  the  sample  implementations  of  those  practices. 

Determine  whether  the  implementations  for  a  particular  product  are  simple  or  complex, 
inexpensive  or  costly.  This  will  aid  you  in  performing  necessary  trade-offs. 

>  Based  on  your  organization ’s  security ? needs,  identify'  specific  security-related  features  that 
you  want  in  the  sewer  product  you  will  be  selecting. 

This  may  include  types  of  authentication,  levels  of  access  control,  support  for  remote 
administration,  and  logging  features. 

>  Check  with  available  sources  of  incident  data  to  help  determine  the  likelihood  of 
particular  kinds  of  incidents  and  the  vulnerabilities  of  specific  servers. 

Vendor  Web  sites  often  contain  this  information.  CERT®1  advisories,  summaries, 
vulnerability  notes,  and  incident  notes2  will  occasionally  present  information  about  new 
vulnerabilities  in  server  software. 


1.  Registered  in  the  U.S.  Patent  and  Trademark  Office. 

2.  See  http://www.cert.org. 
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The  vendor  sites  may  also  present  information  about  the  operating  systems  under  which 
they  operate. 

>  Identify  candidate  products  that  meet  your  functionality,  performance ,  and  securin' 
requirements. 

>  Estimate  the  differences  in  operating  costs  of  competing  products ,  including  the  business 
costs  of  potential  securin'  incidents  and  the  amount  of  staff  effort  required  to  operate, 
maintain,  and  use  each  product. 

A  useful  way  to  make  an  informed  decision  is  to  compare  the  costs  of  installing  and 
maintaining  security  products  with  the  costs  of  staff  time  to  identify,  analyze,  and  recover 
from  a  security  incident,  including  lost  productivity  of  other  staff  during  the  time  they 
cannot  use  any  compromised  systems. 

>  Select  the  technology  that  you  believe  offers  the  best  balance  of  functionality, 
performance,  security',  and  overall  cost. 


Policy  considerations  Your  organization’s  networked  systems  security  policy  should  require  a  security 

evaluation  as  part  of  your  computing  and  network  technology  selection  procedures3. 

In  addition,  we  recommend  that  your  organization’s  purchasing  guidelines  mandate  the 
specification  of  security  requirements  for  all  computing  and  network  technologies. 


Where  to  find  updates  The  latest  version  of  this  practice,  plus  implementation  details  for  selected  technologies,  is 

available  on  the  Web  at  URL 

http://www.cert.org/security-improvement/practices/p066.html 


3.  Refer  to  a  US  Government  publication  titled  Information  Security  Risk  Assessment,  Practices  of 
Leading  Organizations  (GAO/AIMD-OO-33).  This  was  published  by  the  United  States  General 
Accounting  Office  in  Washington,  D.C.  in  November  1999. 
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Keep  operating  systems  and  applications  software  up 
to  date. 


You  need  to  stay  informed  of  vendors’  security-related  updates  to  their  products,  which 
may  be  called  updates,  upgrades,  patches,  service  packs,  hot  fixes,  or  workarounds. 
Whenever  an  update  is  released,  you  need  to  evaluate  it,  determine  if  it  is  applicable  to 
your  organization’s  computers,  and,  if  so,  install  it. 


Why  this  is  important  Because  software  systems  are  so  complex,  it  is  common  for  security-related  problems  to 

be  discovered  only  after  the  software  has  been  in  widespread  use.  Although  most  vendors 
try  to  address  known  security  flaws  in  a  timely  manner,  there  is  normally  a  gap  from  the 
time  the  problem  is  publicly  known,  the  time  the  vendor  requires  to  prepare  the  correction, 
and  the  time  you  install  the  update.  This  gap  gives  potential  intruders  an  opportunity  to 
take  advantage  of  this  flaw  and  mount  an  attack  on  your  computers  and  networks.  To  keep 
this  time  interval  as  short  as  possible,  you  need  to  stay  aware  of 

•  announcements  of  security-related  problems  that  may  apply  to  your  systems 

•  immediate  steps  you  can  take  to  reduce  your  exposure  to  the  vulnerability,  such  as 
disabling  the  affected  software 

•  permanent  fixes  from  vendors 

Installing  applicable  vendors’  updates  can  reduce  your  vulnerability  to  attack. 


How  to  do  it  V  Develop  and  maintain  a  list  of  sources  of  information  about  security  problems  and 

software  updates  for  your  system  and  application  software. 

The  most  common  sources  of  current  information  include  Web  sites  of  vendors  and 
computer-  and  network- security  organizations.1  There  are  also  mailing  lists,  some  of 
which  are  sponsored  by  vendors,  and  USENET  news  groups. 

Lists  and  Web  sites  appear,  disappear,  and  change  frequently.  You  need  to  ensure  that  the 
sources  you  consult  are  up-to-date. 

>  Establish  a  procedure  for  monitoring  those  information  sources. 

In  the  case  of  mailing  lists,  you  usually  receive  announcements  about  security  problems 


1 .  For  example,  the  CERT/CC  site  at  http://www.cert.org  and  Preparing  to  Detect  Signs  of 

Intrusion  [Kochmar  98],  specifically  the  implementation  “Maintaining  currency  by  periodically 
reviewing  public  and  vendor  information  sources.”  This  implementation  is  available  at  http:// 
www.cert.org/security-improvement/implementations/i040.01.html.  Also,  refer  to  http:// 
www.sans.org  to  subscribe  to  their  various  mailing  lists. 
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and  software  updates  soon  after  they  are  available.  Web  sites  vary  considerably  in  the 
timeliness  of  their  announcements,  so  you  need  to  decide  how  often  to  look  for 
information  there.  Some  of  the  news-oriented  Web  sites  arc  updated  one  or  more  times  a 
day,  so  daily  monitoring  is  recommended. 

>  Evaluate  updates  for  applicabilit}'  to  your  systems. 

Not  all  updates  are  applicable  to  the  configuration  of  the  computers  and  networks  in  your 
organization  and  to  your  organization's  security  requirements. 

Evaluate  all  the  updates  to  determine  their  applicability,  and  weigh  the  cost  of  deploying 
an  update  against  the  benefits.  Keep  in  mind  that  failure  to  install  a  vendor  patch  may 
result  in  a  known  vulnerability  being  present  in  your  operational  configuration. 

>*  Plan  the  installation  of  applicable  updates. 

The  installation  of  an  update  can  itself  cause  security  problems: 

•  During  the  update  process,  the  computer  may  temporarily  be  placed  in  a  more 
vulnerable  state. 

•  If  the  update  is  scheduled  inappropriately,  it  might  make  a  computer  or  information 
resources  unavailable  when  needed. 

•  If  an  update  must  be  performed  on  a  large  number  of  computers,  there  can  be  a  period 
of  time  when  some  computers  on  the  network  are  using  different  and  potentially 
incompatible  versions  of  software,  which  might  cause  information  loss  or  corruption. 

•  The  update  may  introduce  new  vulnerabilities. 

Updates  can  also  cause  a  number  of  problems  in  other  installed  software.  You  may  want  to 
consider  running  a  previously  developed  regression  test  suite  to  compare  current 
performance  with  past  performance.  Another  approach  is  to  install  the  update  in  an 
isolated  test  environment  and  run  a  series  of  user  trials  before  releasing  the  update  on  your 
operational  systems. 

Software  packages  are  available  that  show  you  the  differences  in  the  system  as  a  result  of 
installing  the  update.  We  recommend  that  you  use  one  of  these  to  fully  understand  and 
analyze  the  effects  of  the  update  on  your  systems. 

In  addition,  you  should  always  backup  your  system  prior  to  applying  any  updates. 

Any  method  of  updating  that  depends  on  an  administrator  physically  visiting  each 
computer  is  labor  intensive  but  will  work  for  networks  with  a  small  number  of  computers 
You  will  need  to  employ  automated  tools  to  roll-out  updates  to  a  large  number  of 
computers.  Some  of  these  tools  are  provided  by  vendors  for  their  specific  products.  You 
may  need  to  develop  tools  that  are  tailored  to  your  environment  if  vendor  tools  arc 
insufficient. 

Given  the  number  and  diversity  of  operating  systems  and  applications,  the  update  process 
can  become  unmanageable  if  it  is  not  supported  by  appropriate  levels  of  automation.  This 
may  result  in  updates  not  being  performed,  which  in  turn  places  your  systems  at  risk  by 
allowing  intruders  to  take  advantage  of  known  vulnerabilities. 

When  using  automated  tools  to  roll-out  updates,  the  affected  computers  and  the  network 
are  likely  to  be  vulnerable  to  attack  during  the  update  process. 
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To  lessen  this  vulnerability,  you  should  use  only  an  isolated  network  segment  when 
propagating  the  updates  or  consider  using  secure  connectivity  tools  such  as  SSH\ 

>  Install  the  updates  using  a  documented  plan . 

Follow  the  plan  developed  in  the  previous  step.  This  helps  ensure  that  you  deploy 
computers  consistently  throughout  your  organization. 

V  Deploy  new  computers  with  up-to-date  software. 

When  new  workstations  and  network  servers  are  being  deployed,  it  is  common  to  install 
the  operating  system  and  other  software  from  the  original  distribution  media  supplied  by 
vendors.  However,  those  software  versions  may  not  include  recent  security-related 
updates.  Maintain  an  archive  of  updates  that  you  have  evaluated  and  chosen  to  install  on 
existing  computers,  so  that  you  can  install  them  on  new  computers  before  deployment. 

Also  acquire  and  install  the  most  up-to-date  driver  software  (often  available  from  vendors’ 
Web  sites)  for  all  components  and  peripheral  devices.  Those  drivers  typically  address 
performance  and  security  issues  that  have  been  discovered  since  the  components  were 
packaged  and  shipped  from  the  factory.  Be  sure  to  read  all  the  release  documentation 
associated  with  the  updated  drivers  before  using  them.  Also,  whenever  possible,  verify  the 
integrity  and  authenticity  of  the  new  driver  software,  using  methods  such  as  cryptographic 
checksums  supplied  by  the  vendor. 

>  After  making  any  changes  in  a  computer’s  configuration  or  its  information  content ,  create 
new  cryptographic  checksums  or  other  integrity-checking  baseline  information  for  that 
computer. 

Integrity  checking  tools  (such  as  Tripwire3)  can  identify  changes  made  to  files  and 
directories  when  you  install  updates.  By  creating  a  baseline  again  and  subsequently 
monitoring  these  changes,  you  can  learn  more  about  how  the  system  is  working  and,  over 
time,  identify  unexpected  changes  that  require  further  investigation. 

Refer  to  the  modules  Detecting  Signs  of  Intrusion  [Firth  97]  and  Preparing  to  Detect  Signs 
of  Intrusion  [Kochmar  98]  for  additional  information  on  the  role  of  checking  the  integrity 
of  baseline  information  to  support  intrusion  detection. 


Policy  considerations  Your  organization’s  security  policy  for  networked  systems  should  require  that  system 

administrators  monitor  the  need  for  necessary  security-related  software  updates  and  install 
them  in  a  timely  manner. 


Other  information  It  is  possible  that  you  may  not  have  enough  information  to  decide  whether  or  not  to  apply 

an  update.  You  also  may  not  have  a  comprehensive  test  environment  in  which  to  evaluate 
the  effects  of  an  update.  If  either  of  these  is  the  case,  we  recommend  that  you  implement 
the  steps  in  this  practice  to  an  extent  that  is  both  possible  and  practical.  You  should  then 
try  to  recognize  and  manage  any  remaining  risks  of  exposure. 


2.  Refer  to  the  implementation  “Installing,  configuring,  and  operating  the  secure  shell  (SSH)  on 
system  running  Solaris  2.x”  available  at  http://www.cert.org/security-improvement/ 
implementations/i062.01  .html. 

3.  Refer  to  http://www.cert.org/security-improvement/implementations/i002.02.html. 
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Where  to  find  updates 


The  latest  version  of  this  practice,  plus  implementation  details  for  selected  technologies,  is 
available  on  the  Web  at  URL 

http://www.cert.org/security-improvement/practices/p067.html 
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Offer  only  essential  network  services  and  operating 
system  services  on  the  server  host  machine. 


Ideally,  each  network  service  should  be  on  a  dedicated,  single-purpose  host.  Many 
computers  are  configured  by  default  to  provide  a  wider  set  of  services  and  applications 
than  required  to  provide  a  particular  network  service,  so  you  may  need  to  configure  the 
server  to  eliminate  or  disable  them. 


Why  this  is  important  Offering  only  the  essential  network  services  on  a  particular  host  can  enhance  your  network 

security  in  several  ways: 

•  Other  services  cannot  be  used  to  attack  the  host  and  impair  or  remove  desired  network 
services.  Each  additional  service  added  to  a  host  increases  the  risk  of  compromise  for 
all  services  on  that  host  or  for  any  computer  trusting  that  host. 

•  Different  services  may  be  administered  by  different  individuals.  By  isolating  services 
so  each  host  and  service  has  a  single  administrator,  you  will  minimize  the  possibility  of 
conflicts  between  the  administrators  (also  known  as  separation  of  duties). 

•  The  host  can  be  configured  to  better  suit  the  requirements  of  the  particular  service. 
Different  services  might  require  different  hardware  and  software  configurations,  which 
could  lead  to  needless  vulnerabilities  or  service  restrictions. 

•  By  reducing  services,  the  number  of  logs  and  log  entries  is  reduced,  so  detecting 
unexpected  behavior  becomes  easier. 


How  to  do  it  We  strongly  recommend  that  you  use  the  configuration  principle  “deny  first,  then  allow.” 

That  is,  turn  off  as  many  services  and  applications  as  possible  and  then  selectively  turn  on 
only  those  that  are  absolutely  essential.  We  recommend  you  install  the  most  minimal 
operating  system  configuration  image  that  meets  your  business  requirements. 

>  Determine  the  functions  that  you  intend  to  support  with  your  network  server. 

The  services  you  enable  on  a  selected  host  depend  on  the  functions  you  want  the  host  to 
provide.  Functions  could  support  the  selected  network  service,  other  services  hosted  on 
this  computer,  or  development  and  maintenance  of  the  operating  system  and  applications. 
Providing  multiple  services  or  combining  the  role  of  workstation  and  server  on  the  same 
machine  results  in  a  less  secure  configuration  and  makes  security  maintenance  more 
difficult. 

Determine  the  configuration  of  the  host  for 

•  file  systems  (e.g.,  whether  any  file  services  will  be  used  by  this  host.  NFS  should  be 
avoided  as  it  has  many  known  vulnerabilities.) 

*  system  maintenance  (e.g.,  with  multiuser  systems,  whether  all  maintenance  will  be 
done  only  via  the  console  or  remotely) 
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•  server  maintenance.  In  most  cases,  all  server  software  maintenance  should  be  done  on 
another  host  and  the  updated  files  downloaded  to  this  host.  No  compilers,  editors, 
interpreters,  shells,  scripts,  or  other  programming  tools  should  be  available  on  a  server 
providing  specific  services  or  applications  (as  contrasted  with  a  server  being  used  for 

internal  development).1 

•  network  configuration  (DNS  vs.  NIS).  Consider  including  a  list  of  trusted  hosts  and 
other  computers  which  will  be  in  communication  with  your  computer.  This  helps 
protect  against  DNS  spoofing.  Be  aware  that  this  approach  will  take  more  time; 
information  is  replicated  and  any  updates  must  be  performed  on  each  host  to  keep  this 
information  consistent. 

•  protocols  offered  (IP,  IPX,  AppleTalk,  DecNet,  etc.) 

•  printing.  Some  printing  subsystems  have  known  vulnerabilities  and  should  be  removed 
or  disabled,  where  possible. 

>  If  there  are  alternative  ways  of  providing  the  same  function ,  select  the  more  secure  way. 

For  example,  on  UNIX  systems,  connectivity  for  remote  system  maintenance  (i.e.,  not 
from  the  console)  could  be  supported  using  remote  shell  (RSH)  or  secure  shell  (SSH).“  We 
recommend  disabling  all  r-services3  due  to  their  inherent  vulnerabilities  (use  of  IP 
addresses  for  authentication).  Therefore,  SSH  is  the  more  secure  alternative  and  should  be 
selected. 

Use  wrapper  tools  such  as  TCP  wrapper4  for  controlling  access  to  selected  services  by  IP 
address  and  to  log  all  connection  attempts  to  those  services  (such  as  telnet).  Be  aware  that 
TCP  wrapper  does  not  protect  against  IP  spoofing;  however,  such  connection  attempts  and 
successful  connections  would  be  logged. 

>  Once  you  determine  the  minimal  set  of  services  and  applications,  ensure  that  only  those 
are  installed  on  the  host. 

Either  do  not  install  unnecessary  services  or  turn  the  services  off  and  remove  the 
corresponding  files  (and  any  other  unnecessary  files)  from  the  host.  Be  careful  with 
network  service  programs.  Some  provide  multiple  services  and  you  will  have  to 
reconfigure  them  or  disable  unneeded  services.  For  example,  Web  server  software  often 
includes  FTP  along  with  HTTP.  Disable  FTP  if  you  do  not  intend  to  support  file  transfers 
to  and  from  your  public  Web  site.  If  you  need  to  retain  the  FTP  service,  severely  restrict 
access  to  it  and  disable  the  use  of  anonymous  FTP. 

When  considering  services  to  enable  or  disable,  administrators  typically  think  of  those 
services  that  run  as  processes.  This  includes,  for  example,  telnet,  FTP,  DNS,  electronic 
mail,  and  Web  services.  However,  most  of  today’s  systems  also  provide  services  directly 
from  the  kernel.  An  example  would  be  a  netmask  request.  That  request  is  typically 
broadcast  onto  the  local  area  network,  and  all  systems  that  see  that  request  answer  it,  if  not 
otherwise  instructed.  The  kernel  of  those  answering  systems  is  providing  the  netmask 
service,  more  than  likely  unbeknownst  to  the  administrator  of  that  computer. 


1.  If  programming  tools  are  required,  locate  them  in  separate,  protected  directories.  Locate  public 
scripts  in  a  single  protected  “execute  only”  directory. 

2.  Refer  to  the  implementation  “Installing,  configuring,  and  operating  the  secure  shell  (SSH)  on 
systems  running  Solaris  2.x”  available  at  http://www.cert.org/security-improvementy 
implementations/i062.01  .html. 

3.  rpc,  rdate,  rdist,  remsch,  rlogin,  rpcinfo,  rsh,  rksh,  rup,  ruptime,  rusers,  rwho 

4.  Refer  to  the  implementation  “Installing,  configuring,  and  using  TCP  wrapper  to  log  unauthorized 
connection  attempts  on  systems  running  Solaris  2.x”  available  at  http://www.cert.org/security- 
improvement/implementations/i 04 1.07. html. 
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You  need  to  determine  what  services  are  provided  by  the  kernel  and  what  controls  the 
operating  system  provides  to  configure  those  services.  These  services  are  frequently  not 
documented  and  are  often  not  controllable.  There  is  no  tool  that  we  know  of  to  test  for  the 
presence  of  such  services  in  a  manner  similar  to  the  way  the  strobe  tool  for  UNIX  systems 
tests  for  services  running  as  processes.  The  best  source  of  information  is  the  system 
vendor. 

We  recommend  that  you  configure  computers  to  offer  only  the  services  that  your 
deployment  plan  specifies  they  should  provide. 

>■  Eliminate  any  unnecessary'  open  network  ports . 

Eliminate  unnecessary  TCP  and  UDP  network  ports  on  which  a  server  process  may  listen 
for  incoming  client  connections.  This  reduces  the  risk  of  attack  using  these  ports.  Open 
network  ports  can  be  identified  using  the  netstat  command  on  UNIX  and  Windows  95/98/ 
NT  systems. 

>  After  you  make  all  configuration  choices ,  create  and  record  cryptographic  checksums  or 
other  integrity-checking  baseline  information  for  your  critical  system  software  and  its 
configuration . 

Refer  to  the  practice  “Generate  information  required  to  verify  the  integrity  of  your 
systems  and  data.”  in  the  module  Preparing  to  Detect  Signs  of  Intrusion  [Kochmar  98]. 


Policy  considerations  Your  organization’s  security  policy  for  networked  systems  should  require  that 

•  individual  network  servers,  including  public  servers,  be  configured  to  offer  only 
essential  services 

•  each  network  service  be  on  a  dedicated,  single-purpose  host  where  possible 


Other  information  Refer  to  Web  Security 1  &  Commerce  [Garfinkel  97],  pp.  268-270,  “Minimizing  Risk  by 

Minimizing  Services.” 

You  may  need  to  configure  the  server  differently  according  to  the  other  features  provided 
by  the  selected  host  operating  system  or  environment.  For  example,  certain  operating 
systems  provide  extensive  access  control  mechanisms  that  minimize  or  prevent  the 
possibility  of  unauthorized  access  at  relatively  fine  levels  of  granularity. 


Where  to  find  updates  The  latest  version  of  this  practice,  plus  implementation  details  for  selected  technologies,  is 

available  on  the  Web  at  URL 

http://www.cert.org/security-improvement/practices/p068.html 
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Configure  computers  for  user  authentication. 


An  organization’s  security  policy  for  networked  systems  should  specify  that  only 
authorized  users  may  access  the  computers.  To  enforce  this,  you  need  to  configure  the 
computer  to  authenticate  a  prospective  user,  who  must  prove  that  they  are  authorized  for 
such  access. 

Configuring  the  computer  for  authentication  usually  involves  configuring  parts  of  the 
operating  system,  firmware,  and  applications  such  as  the  software  that  implements  a 
network  service.  If  your  organization  has  authentication  servers,  configuring  a  new 
workstation  or  network  server  for  user  authentication  may  require  you  to  make 
configuration  changes  on  another  computer.  In  special  cases,  you  may  also  use 
authentication  hardware  such  as  tokens,  one-time  password  devices,  or  biometric  devices 
(devices  that  can  recognize  a  person  based  on  biological  characteristics,  such  as 
fingerprints  or  patterns  in  retinal  blood  vessels). 


Why  this  is  important  Unauthorized  users  can  jeopardize  the  security  of  information  stored  on  or  accessible  from 

a  computer.  To  prevent  this,  you  must  configure  the  computer  to  authenticate  all  users  who 
attempt  access. 


How  to  do  it  This  practice  is  most  effective  if  you  include  it  as  part  of  the  initial  installation  and 

configuration  of  the  operating  system. 

Your  deployment  plan  documents  the  users  or  user  categories  and  the  approach  to 
authenticating  those  users.  The  following  steps  describe  how  to  implement  that  part  oi  the 
plan. 

>  Configure  the  system  to  use  hardware-based  access  controls ,  if  available. 

If  the  computer’s  firmware  offers  the  feature  of  requiring  a  password  when  the  system  i- 
turned  on,  enable  that  feature  and  set  the  password.  This  feature  is  sometimes  know  n  ^  a 
BIOS  or  EEPROM  password. 

Enabling  this  feature  will  require  your  intervention  if  the  system  crashes  because  you  can't 
configure  the  computer  to  restart  automatically.  This  is  usually  acceptable  for 
workstations  because  if  the  user  is  not  present,  it  is  not  necessary  to  restart  the  computer 
immediately.  However,  enabling  this  feature  can  present  problems  for  network  servers, 
which  normally  operate  24  hours  a  day.  When  the  system  crashes,  an  administrator  may 
not  be  available  to  restart  the  system. 


CMU/SEI-SIM-010 


25 


Remove  unneeded  default  accounts  and  groups. 

The  default  configuration  of  the  operating  system  often  includes  guest  accounts  (with  and 
without  passwords),  administrator  accounts,  and  accounts  associated  with  local  and 
network  services.  The  names  and  passwords  for  those  accounts  are  well  known.  Remove 
or  disable  unnecessary  accounts  to  eliminate  their  use  by  intruders,  including  guest 
accounts  on  computers  containing  sensitive  information.  If  you  do  have  the  requirement  to 
retain  a  guest  account  or  group,  severely  restrict  its  access  and  change  the  password  in 
accordance  with  your  password  policy. 

For  default  accounts  that  you  need  to  retain,  change  the  names  (where  possible  and 
particularly  for  administrator  accounts)  and  passwords  to  be  consistent  with  your 
password  policy.  Default  account  names  and  passwords  for  default  accounts  are 
commonly  known  in  the  intruder  community. 

Disable  non-interactive  accounts. 

Disable  accounts  (and  the  associated  passwords)  that  need  to  exist  but  do  not  require  an 
interactive  login.  For  UNIX  systems,  disable  the  login  shell  or  provide  a  login  shell  with 
NULL  functionality  (/bin/false). 

Create  the  user  groups  for  the  particular  computer. 

Assign  users  to  the  appropriate  groups.  Then  assign  rights  to  the  groups,  as  documented  in 
your  deployment  plan.  This  approach  is  preferable  to  assigning  rights  to  individual  users. 

Create  the  user  accounts  for  the  particular  computer. 

Your  deployment  plan  identifies  who  will  be  authorized  to  use  each  computer  and  its 
services.  Create  only  the  necessary  accounts.  Discourage  or  prohibit  the  use  of  shared 
accounts. 

Check  your  password  policy,  and  set  account  passwords  appropriately. 

A  password  policy  should  address 

•  length:  a  minimum  length  for  passwords.  It  is  common  to  specify  a  minimum  length  of 
eight  characters. 

•  complexity:  the  mix  of  characters  required.  It  is  common  to  require  passwords  to 
contain  both  uppercase  and  lowercase  letters  and  at  least  one  nonalphabetic  character. 

•  aging:  how  long  a  password  may  remain  unchanged.  It  is  common  to  require  users  to 
change  their  passwords  periodically  (every  30-120  days).  The  policy  should  permit 
users  to  do  so  only  through  approved  authentication  mechanisms. 

•  reuse:  whether  a  password  may  be  reused.  Some  users  try  to  defeat  a  password  aging 
requirement  by  changing  the  password  to  one  they  have  used  before. 

•  authority:  who  is  allowed  to  change  passwords 
Ensure  users  follow  your  password  policy. 

Document  your  password  policy,  communicate  it  to  users,  and  train  them  to  always  follow 
the  policy. 

Configure  the  password-setting  software  to  reject  passwords  that  don’t  conform  to  your 
policy,  if  the  operating  system  provides  this  feature. 
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If  permitted  by  policy,  for  UNIX  systems  you  may  want  to  consider  using  npasswd.1 2  This 
tool  checks  passwords  as  they  are  entered  by  users  to  ensure  compliance  with  some 
aspects  of  your  password  policy. 

Also  if  permitted  by  policy,  an  authorized  system  administrator  can  use  tools  such  as 
crack'  to  review  all  passwords  to  determine  that  they  cannot  be  easily  compromised  and  to 
ensure  compliance  with  some  aspects  of  your  password  policy. 

V  Configure  computers  to  require  reauthentication  after  idle  periods . 

This  step  is  most  useful  for  workstations,  but  consider  it  for  network  servers  as  well, 
especially  if  the  server  will  be  administered  from  the  console. 

Most  operating  systems  include  software  to  display  a  changing  image  (screensaver)  on  a 
monitor  or  software  (locking  screensaver)  to  power  down  monitors  and  disks  (energy 
saver)  after  a  short  period  of  inactivity.  This  inactivity  may  indicate  that  the  workstation  is 
unattended  though  a  user  is  still  logged  in.  Requiring  reauthentication  when  the  user 
returns  minimizes  the  risk  of  an  unauthorized  person  using  an  active  session  while  the 
authorized  user  is  away. 

If  possible,  configure  the  operating  system  to  terminate  a  remote  or  terminal  session  (log 
out)  and  start  a  locking  screen  saver  after  a  specified  idle  period  (typically  between  two 
and  ten  minutes  depending  on  the  sensitivity  of  access  to  the  host).  If  this  is  not  available, 
acquire  and  install  third-party  software  to  provide  this  capability. 

Consider  requiring  users  to  shut  down  or  lock  computers  when  they  leave  the  machine 
unattended.  This  prevents  a  period  of  vulnerability  between  the  time  the  user  leaves  and 
the  time  the  locking  screensaver  is  activated.  Hardware-based  authentication  systems  such 
as  chipcards  can  be  used  to  lock  computers  when  the  user  takes  the  chipcard  out  of  its 
reader. 

>*  Configure  computers  to  deny  login  after  a  small  number  of  failed  attempts. 

It  is  relatively  easy  for  an  unauthorized  user  to  try  to  gain  access  to  a  computer  by  using 
automated  software  tools  that  attempt  all  passwords.3  If  your  operating  system  provides 
the  capability,  configure  it  to  deny  login  after  three  failed  attempts.  Typically,  the  account 
is  “locked  out”  for  a  period  of  time  (such  as  30  minutes)  or  until  a  user  with  appropriate 
authority  reactivates  it. 

This  is  another  situation  that  requires  you  to  make  a  decision  that  balances  security  and 
convenience.  Implementing  this  recommendation  can  help  prevent  some  kinds  of  attacks, 
but  it  can  also  allow  a  malicious  intruder  to  make  failed  login  attempts  to  eliminate  user 
access  —  a  denial  of  service  condition.  You  may  not  consider  this  configuration 
acceptable  for  network  servers  because  it  makes  the  server  unavailable  to  the  authorized 
user  whose  account  logins  failed. 

In  some  cases,  you  need  to  distinguish  between  failed  login  attempts  at  the  console  and 
those  coming  in  through  the  network. 


1.  Refer  to  the  implementation  “Installing,  configuring,  and  using  npasswd  to  improve  password 
quality  on  systems  running  Solaris  2.x.”  It  is  available  at  http://www.cert.org/security- 

i  mpro  vement/i  mplementations/i028 .05 . 

2.  ftp://coast.cs.purdue.edu/pub/tools/unix/crack/ 

3.  The  time  required  to  attempt  all  passwords  will  depend  on  network  speed  and  server  performance 
capabilities  but  an  unauthorized  user  can  certainly  attempt  common  passwords  in  a  reasonable 
period  of  time. 
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Failed  network  login  attempts  should  not  prevent  an  authorized  user  or  administrator  from 
logging  in  at  the  console.  Note  that  all  failed  login  attempts  should  be  logged.4 


Policy  considerations 


Install  and  configure  other  authentication  mechanisms  as  required  by  your  organization  s 
security'  plan  and  policies. 

Consider  using  other  authentication  mechanisms  such  as  tokens,  one-time  password 
systems,  and  biometric  hardware  and  software.  They  can  be  expensive,  but  they  may  be 
justified  in  some  circumstances. 

Passwords  passed  across  a  network  in  clear  text  can  be  easily  captured  by  intruders  using 
network  sniffers.  Consider  implementing  authentication  and  encryption  technologies  such 
as  SSH5  and  SSL6. 

For  network  servers ,  configure  the  authentication  capability'  of  the  network  service 
software ,  if  any. 

The  authentication  capabilities  of  network  service  software  packages  vary.  Note  that  some 
packages  provide  their  own  mechanisms  for  authenticating  users,  while  others  depend  on 
the  underlying  operating  system.7  Be  sure  that  both  are  configured  appropriately  and  that 
they  reinforce  and  do  not  conflict  with  one  another. 


Your  organization’s  policy  for  networked  systems  should 

•  describe  under  what  conditions  an  account  is  created  and  deleted.  This  should  include 
what  account  actions  are  taken  (disabled,  deleted,  transferred)  and  how  files  are 
handled  when  an  employee,  contractor,  or  vendor  who  has  an  account  on  your  systems 
no  longer  works  for  your  organization. 

•  require  appropriate  authentication  of  all  users  on  all  computers  that  can  access 
information  resources;  this  includes  authenticating  users  of  network  services  hosted  by 
your  servers 

•  include  an  appropriate  password  policy 

•  prohibit  users  from  recording  and  storing  passwords  in  places  that  could  be  discovered 
by  intruders 

Your  organization’s  acceptable  use  policy  for  workstations  should  require  that  users  shut 

down  or  lock  their  unattended  workstations. 


4.  Refer  to  the  modules  Detecting  Signs  of  Intrusion  [Firth  97]  and  Preparing  to  Detect  Signs  of 
Intrusion  [Kochmar  98]. 

5.  Refer  to  the  implementation  “Installing,  configuring,  and  operating  the  secure  shell  (SSH)  on 
systems  running  Solaris  2.x.”  It  is  available  at  http://www.cert.org/security-improvement/ 
implementations/i062.01  .html. 

6.  Refer  to  the  module  Securing  Public  Web  Servers  [Kossakowski  00],  specifically  the  practice 
“Configure  the  Web  server  to  use  authentication  and  encryption  technologies,  where  required.”  It 
is  available  at  http://www.cert.org/security-improvement/practices/p080.html. 

7.  Be  aware  that  proprietary,  closed  authentication  mechanisms  used  by  such  packages  are  not 
necessarily  secure. 
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Where  to  find  updates 


When  writing  a  password  policy,  remember  that  requiring  users  to  have  complex 
passwords  may  have  the  undesired  result  of  users  writing  their  passwords  on  paper  that 
they  keep  near  the  computer  (often  stuck  to  the  machine)  or  with  personal  papers  (in  a 
wallet,  purse,  or  briefcase).  If  that  paper  is  observed,  lost,  or  stolen,  it  creates  a  potential 
vulnerability. 

If  a  password  policy  is  especially  difficult  to  follow,  it  creates  in  users  a  desire  to  find 
ways  around  it.  This  attitude  can  negatively  influence  users’  compliance  with  other 
aspects  of  security  policies. 


The  latest  version  of  this  practice,  plus  implementation  details  for  selected  technologies,  is 
available  on  the  Web  at  URL 

http://wwwxert.org/security-improvement/practices/p069.html 
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Configure  computer  operating  systems  with 
appropriate  object,  device,  and  file  access  controls. 


Many  operating  systems  provide  the  capability  to  specify  access  privileges  individually 
for  files,  directories,  devices,  and  other  data  or  code  objects.  We  recommend  that  you 
configure  the  settings  on  files  and  other  objects  to  take  advantage  of  this  capability  and 
protect  information  stored  on  the  computer. 


Why  this  is  important  By  carefully  setting  access  controls,  you  can  reduce  both  intentional  and  unintentional 

security  breaches.  For  example,  denying  read  access  helps  to  protect  confidentiality  of 
information,  and  denying  unnecessary  write  (modify)  access  can  help  maintain  the 
integrity  of  information.  Limiting  the  execution  privilege  of  most  system-related  tools  to 
authorized  system  administrators  can  prevent  most  users  from  making  configuration 
changes  that  could  reduce  security.  It  also  can  restrict  the  ability  of  intruders  to  use  those 
tools  to  attack  the  system  or  other  systems  on  the  network. 


How  to  do  it  Implement  access  controls  during  initial  installation  and  configuration  of  the  operating 

system  and  carefully  monitor  and  maintain  them  thereafter. 

>  Identify  the  protection  needed  for  files,  directories,  devices,  and  objects  on  the  computer. 

One  method  that  you  can  use  to  identify  needed  protection  is  to  construct  a  matrix  with 
categories  of  files  and  objects  on  one  axis  and  groups  of  users  (defined  by  roles  and  access 
authority)  on  the  other.  Then  record  in  the  matrix  the  kinds  of  access  privileges  allowed 
for  that  class  of  objects  and  that  class  of  users.  The  privileges  are  based  on  the  security 
requirements  (such  as  confidentiality,  integrity,  and  availability)  of  the  various  classes  of 
resources. 

For  example,  you  may  have  file  categories  that  include  administrative  information  (user 
names,  passwords,  privileges,  etc.),  applications,  development  tools,  operating  system 
files,  and  user  data  files.  The  latter  may  be  further  subdivided  into  categories  such  as 
customer  accounts,  inventory  records,  research  data,  and  management  reports.  You  may 
have  user  groups  that  include  system  administrators,  network  service  daemons,  and  users 
from  various  departments. 

As  you  begin  to  identify  privileges,  you  may  need  to  split  some  rows  and  columns.  This 
happens,  for  example,  when  you  discover  that  a  single  group  of  users  is  really  two  groups 
because  their  need  to  access  a  particular  resource  is  not  uniform. 

You  may  also  want  to  distinguish  local  access  privileges  from  network  access  privileges 
for  a  class  of  files. 
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Application  programs  may  request  and  be  granted  increased  access  privileges  for  some  of 
their  operations — a  change  that  is  not  obvious  to  the  users  of  that  application.  You  may  not 
want  all  those  users  to  have  increased  privileges.  Therefore,  it  is  important  to  take  great 
care  in  assigning  privileges  to  users  and  groups. 

V  Create  the  needed  user  groups. 

When  you  take  the  previous  step,  you  may  identify  categories  of  users  not  sufficiently 
detailed  in  the  computer  deployment  plan.  Configure  the  operating  system  to  recognize 
the  needed  user  groups,  and  then  assign  individual  users  (including  network  service 
daemons)  to  the  appropriate  groups. 

>  Configure  access  controls . 

Configure  access  controls  for  all  protected  files,  directories,  devices,  and  other  objects, 
using  the  matrix  created  in  the  first  step  above  as  a  guide.  Every  change  or  decision  not  to 
change  each  object’s  permission  should  be  documented  along  with  the  rationale. 

Disable  write/modify  access  permissions  for  all  executable  and  binary  files. 

Restrict  access  of  operating  system  source  files,  configuration  files,  and  their  directories  to 
authorized  administrators. 

For  UNIX  systems,  there  should  be  no  world-writable  files  unless  specifically  required  by 
necessary  application  programs.  For  NT  systems,  there  should  be  no  permissions  set  such 
that  “the  Everyone  group  has  Modify  permissions  to  files.” 

For  UNIX  systems,  if  possible,  mount  file  systems  as  read  only  and  nosuid  to  preclude 
unauthorized  changes  to  files  and  programs. 

Assign  an  access  permission  of  immutable  to  all  kernel  files  if  it  is  supported  by  the 
operating  system  (such  as  Linux). 

Establish  all  log  files  as  “append  only”  if  that  option  is  available. 

As  a  goal,  preclude  users  from  installing,  removing,  or  editing  scripts  without 
administrative  review.  We  realize  this  is  difficult  to  enforce. 

Pay  attention  to  access  control  inheritance  when  defining  categories  of  files  and  users. 
Ensure  that  you  configure  the  operating  system  so  that  newly  created  files  and  directories 
inherit  appropriate  access  controls,  and  that  access  controls  propagate  down  the  directory 
hierarchies  as  intended  when  you  assign  them. 

Many  of  an  administrator’s  security  directives  can  be  overridden  on  a  per-directory  basis. 
The  convenience  of  being  able  to  make  local  exceptions  to  global  policy  is  offset  by  the 
threat  of  a  security  hole  being  introduced  in  a  distant  subdirectory  —  which  could  be 
controlled  by  a  hostile  user.  Administrators  should  disable  a  subdirectory's  ability  to 
override  top-level  security  directives  unless  that  override  is  required. 

>  Install  and  configure  file  encryption  capabilities  for  sensitive  data. 

Some  operating  systems  provide  optional  file  encryption;  there  are  also  third-party  file- 
encryption  packages  available.  These  may  be  useful  if  the  operating  system’s  access 
controls  are  insufficient  for  maintaining  the  confidentiality  of  file  contents.  This  can  be  the 
case  if  the  operating  system  provides  few  or  no  access  control  features,  or  when  the 
relationships  among  categories  of  files  and  categories  of  users  are  so  complex  that  it 
would  be  difficult  to  use  only  access  controls  to  administer  the  security  policy. 
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Encryption  adds  complexity,  so  you  need  to  weigh  the  requirement  for  its  use  against  the 
cost  of  using  it. 

The  security  provided  by  strong  access  controls  is  further  enhanced  by  the  use  of 
encryption.  However,  when  you  use  encryption,  you  must  still  dispose  of  unencrypted 
versions  of  the  data 

•  that  existed  prior  to  encryption  being  performed 

•  that  remain  after  decrypting 

•  that  is  used  in  the  encryption  process 

Note  that  this  recommendation  pertains  only  to  encryption  of  files  stored  on  the  computer 
itself.  Encryption  of  information  for  transmission  over  a  network  is  a  separate  issue  that  is 
not  within  the  scope  of  this  practice. 


Policy  considerations  Your  organization’s  security  policy  for  networked  systems  should  specify 

•  access  privileges  and  controls  for  the  information  that  will  be  stored  on  computers 

•  how  access  to  files  that  have  been  encrypted  with  a  user  key  is  performed.  This  is  very 
important  when  that  user  no  longer  works  for  your  organization. 


Other  information  Some  operating  systems  provide  more  than  one  file  system  w'ith  different  access  control 

capabilities.  It  is  important  to  choose  the  file  system  that  best  meets  your  needs  for  file 
access  control.  Your  decision  may  affect  the  low-level  formatting  of  storage  devices  and 
thus  should  be  made  early  in  the  process  of  configuring  the  operating  system. 


Where  to  find  updates  The  latest  version  of  this  practice,  plus  implementation  details  for  selected  technologies,  is 

available  on  the  Web  at  URL 

http://www.cert.org/security-improvement/practices/p070.html 
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Identify  and  enable  system  and  network  logging 
mechanisms. 


Collecting  data  generated  by  system,  network,  application,  and  user  activities  is  essential 
for  analyzing  the  security  of  these  assets  and  detecting  signs  of  intrusion.  Log  files  contain 
information  about  past  activities.  Different  systems  provide  various  types  of  logging 
information;  some  systems  do  not  collect  adequate  information  in  their  default  condition. 
You  should  identify  the  types  of  logs  and  logging  mechanisms  available  for  each  system 
asset  (system  logs,  file  access  logs,  process  logs,  network  logs,  application-specific  logs, 
etc.),  identify  the  data  recorded  within  each  log,  and  then  enable  the  collection  of  the 
desired  data. 


Why  this  is  important  Log  files  are  often  the  only  record  of  suspicious  behavior.  Failure  to  enable  the 

mechanisms  to  record  this  information  and  use  them  to  initiate  alert  mechanisms  will 
greatly  weaken  or  eliminate  your  ability  to  detect  intrusion  attempts  and  to  determine 
whether  or  not  they  succeeded.  Similar  problems  can  result  from  not  having  the  necessary 
procedures  and  tools  in  place  to  process  and  analyze  your  log  files. 

You  may  need  your  logs  to 

•  alert  you  that  something  suspicious  that  requires  further  investigation  has  occurred 

•  determine  the  extent  of  an  intruder’s  activity 

•  help  you  recover  your  systems 

•  provide  information  required  for  legal  proceedings 


How  to  do  it  >  Identify  the  information  to  be  logged. 

Identify 

•  types  of  information  you  can  log 

•  mechanisms  used  for  logging 

•  locations  where  the  logging  is  performed 

•  locations  where  the  log  files  are  stored 
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A  tabic  of  log  categories  and  types  of  log  information  within  each  category  is  shown 
below.  You  may  want  to  use  this  list  as  a  guide  to  the  types  of  information  to  log  (although 
not  all  systems  are  able  to  log  every  type  on  the  list).  Tailor  logging  selections  to  meet 
your  site’s  needs. 


Log  Category 

Types  of  information  to  log 

Users 

•  Login/logout  information:  location  and  time  of  failed  attempts, 
attempted  logins  to  privileged  accounts 

•  Changes  in  authentication  status,  such  as  enabling  privileges 

Processes 

•  Real  and  effective  user  executing  the  process 

•  Process  start-up  time,  arguments 

•  Process  exit  status,  time,  duration,  resources  consumed 

Systems 

•  Actions  requiring  special  privileges 

•  Status/errors  reported  by  hardware  and  software  subsystems 

•  Changes  in  system  status,  including  shutdowns  and  restarts 

Networks 

•  Service  initiation  requests 

•  The  name  of  the  user/host  requesting  the  service 

•  Network  message  traffic  (packets) 

•  New  connections 

•  Connection  duration 

•  Connection  flow 

File  Systems 

•  Changes  to  access  control  lists  and  file  protections 

•  File  accesses  (opening,  creating,  executing,  deleting) 

Applications 

•  Applications-  and  services-specific  information  (e.g.,  mail  logs, 
FTP  logs,  Web  server  logs,  modem  logs,  firewall  logs,  SNMP 
logs) 

If  possible,  do  not  log  passwords,  even  incorrect  ones.  Logging  correct  passwords  creates 
an  enormous  potential  vulnerability  if  a  non-authorized  user  or  intruder  accesses  audit 
records.  Recording  incorrect  passwords  is  also  risky  as  they  often  differ  from  valid 
passwords  by  only  a  single  character  or  transposition.  Turning  off  password  logging  may 
require  resetting  a  system  default.  If  you  cannot  turn  off  password  logging,  you  need  to 
exercise  special  care  in  protecting  access  to  log  files  that  contain  this  information,  as 
described  in  the  last  two  steps  in  this  practice. 

You  may  want  to  log  data  about  password  use  such  as  the  number  of  failed  attempts, 
accesses  to  specific  accounts,  etc. 

>  Determine  if  the  logging  mechanisms  provided  with  your  systems  and  networks 
sufficiently  capture  the  required  information. 

Determine  the  logging  mechanisms  available  for  the  platforms  at  your  site,  how  the  log 
files  are  named,  and  where  they  are  located.  The  names  of  these  log  files  can  differ  even 
among  versions  of  the  same  operating  system  delivered  by  a  single  vendor,  so  it  is 
important  that  you  verify  this  each  time  you  upgrade  your  systems. 

Identify  what  types  of  information  each  logging  mechanism  can  capture.  The  combination 
of  mechanisms  should  capture  the  information  identified  in  the  table  categories  noted 
above.  There  may  be  differences  in  the  log  file  contents  provided  by  different  vendors, 
even  for  similar  types  of  systems. 
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If  the  logging  mechanisms  provided  by  your  vendor  are  insufficient  to  capture  the  data 
you  need,  use  other  tools  to  capture  the  additional  information.  You  may  need  to  develop 
these. 

>  Enable  logging. 

Using  the  logging  mechanisms  provided  by  the  vendor  and  any  supplemental  tools,  enable 
all  logging  that  you  have  selected  from  the  previous  step.  For  help,  refer  to  the 
administration  documentation  for  your  systems  to  learn  how  to  enable  each  of  the  logging 
mechanisms  and  refer  to  documentation  for  other  tools  used  during  setup.  This 
documentation  will  specify  whether  these  mechanisms  need  to  be  enabled  only  once,  each 
time  the  system  is  rebooted,  or  at  regular  intervals  during  the  system’s  normal  operation. 
Some  logging  mechanisms  let  you  select  different  levels  of  detail. 

Pay  attention  to  the  location  of  the  log  data:  some  tools  allow  you  to  specify  a  file  or 
directory  where  the  data  is  logged  while  others  write  their  data  to  a  predefined  default 
location.  Make  sure  that  you  have  sufficient  space  for  the  data  that  is  generated.  Ensure 
that  the  logged  data  is  protected,  based  on  previously  determined  ACLs  (access  control 
lists)  and  your  security  policy. 

Be  aware  that  multiple  logging  mechanisms  may  contribute  log  records  to  a  single  log  file, 
such  as  syslog  in  UNIX  systems.  This  is  specified  within  your  system  configuration  file.1 

>  Protect  logs  to  ensure  they  are  reliable. 

To  protect  sensitive  information,  ensure  that  log  files  are  protected  from  being  accessed  or 
modified  by  unauthorized  users.  Confirm  that  only  authorized  users  can  access  utilities 
that  reconfigure  logging  mechanisms,  turn  the  utilities  on  and  off,  and  write  to,  modify, 
and  read  log  data. 

It  is  important  to  collect  and  archive  log  files  so  that  they  cannot  be  accessed  by  an 
intruder  to  remove  or  alter  signs  of  an  intrusion  or  add  erroneous  information.  Use  the 
following  methods  to  ensure  log  files  are  not  modified: 

•  Log  data  to  a  file  on  a  separate  host  that  is  dedicated  solely  to  log  collecting.  The  log 
host  should  reside  in  a  physically  secure  location  that  is  not  easily  accessible  from  the 
network.  For  example,  capturing  log  data  using  a  computer  via  a  dedicated  serial  line 
provides  a  way  of  storing  the  log  files  more  securely  than  if  they  were  written  on  the 
logging  host’s  disks. 

•  Log  selected  data  to  a  write-once/read-many  device  (such  as  CD-ROM  or  a  specially 
configured  tape  drive)  or  to  a  write-only  device  (such  as  a  printer)  to  eliminate  the 
possibility  of  the  data  being  modified  once  it  is  written. 

•  If  supported  by  your  systems,  set  selected  log  file  attributes  that  enable  only  new 
information  to  be  appended  to  the  log  files  (i.e.,  new  records  can  be  added,  those  already 
recorded  cannot  be  modified). 

•  Encrypt  log  files,  particularly  those  that  contain  sensitive  data  or  those  being  transmitted 
across  a  network. 

Logging  directly  to  disk  on  the  local  host  is  easiest  to  configure  and  allows  instant  access 
to  file  records  for  analysis,  but  it  is  also  the  least  secure.  Collecting  log  files  on  a  write- 
once  device  requires  slightly  more  effort  to  configure  but  is  more  secure.  However,  data  is 
not  as  easily  accessed  and  you  need  to  maintain  a  supply  of  storage  media. 


1.  Refer  to  the  implementation  “Understanding  system  log  files  on  a  Solaris  2.x  operating  system” 
available  at  http://www.cert.org/security-improvement/implementations/i04 1 . 1 2.html. 
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Printing  the  logging  results  is  useful  when  you  require  permanent  and  immediate  log  files, 
but  printed  logs  can  be  difficult  to  search,  require  manual  analysis,  and  require  a 
potentially  large  storage  space. 

When  the  host  generating  the  logging  data  is  different  from  the  host  recording  it,  you  must 
secure  the  path  between  them.  For  environments  where  short  distances  separate  the 
generating  host  from  the  recording  host,  you  can  connect  them  with  single  point-to-point 
cable(s).  For  environments  where  this  approach  is  not  practical,  minimize  the  number  of 
networks  and  routers  used  to  make  the  connection  or  encrypt  sensitive  log  data  as  it  is 
generated. 

You  need  to  prepare  systems  that  perform  logging  to  ensure  that  they  do  not  stop 
functioning  in  the  event  of  a  logging  denial-of-service  attack.  A  UNIX  example  would  be 
an  intruder  launching  an  attack  that  fills  up  the  syslog  files  so  that  when  the  logging 
partition  is  full,  logging  ceases.  Two  means  of  preparation  are  creating  separate  file 
partitions  for  different  log  information  and  filtering  network  messages  to  decrease  the 
likelihood  of  such  attacks. 

>  Document  your  management  plan  for  handling  log  files. 

Handle  the  total  volume  of  logged  information.  We  recommend  that  you  log  as  much  as 
possible  for  your  systems  and  networks.  While  log  files  can  consume  a  great  deal  of 
storage  very  quickly  (which  is  relatively  inexpensive),  it  is  difficult  to  anticipate  which 
logs  will  be  critical  in  the  event  of  an  intrusion.  Based  on  your  log  collection  and  storage 
approach,  you  may  want  to  compress  log  files  to  allow  them  to  remain  accessible  online 
for  easier  review  and  to  conserve  space. 

Determine  what  logging  data  is  most  useful  to  collect.  However,  you  need  to  balance  the 
importance  of  recording  system,  network,  and  user  activities  with  the  resources  available 
to  store,  process,  review,  and  secure  them.  Questions  that  help  you  determine  the 
usefulness  of  logging  data  include 

•  What  is  the  host’s  sole  or  primary  purpose?  For  example,  if  a  host  is  acting  as  a  Web 
server,  you  want  to  capture  Web  logs. 

•  How  many  users  are  assigned  to  the  host  or  system  and  how  important  is  it  for  you  to 
know  who  is  logged  on?  This  helps  you  decide  how  much  login/logout  information  to 
capture. 

•  How  important  is  it  to  be  able  to  use  your  logs  to  recover  a  compromised  system?  This 
helps  you  set  the  priority  for  capturing  information  such  as  data  and  file  transaction 
logs. 

•  What  are  the  range  of  services  that  can  be  performed  on  this  host  or  system?  Process 
accounting  information  is  useful  to  detect  unauthorized  services  and  intruder  actions. 

•  What  is  your  organization’s  ability  and  capacity  to  process  and  analyze  all  collected 
logs  to  obtain  useful  information  when  it  is  needed? 

Rotate  log  files.  This  activity  consists  of 

•  making  a  copy  of  the  active  (online)  log  files  at  regular  intervals  (ranging  from  daily  to 
weekly) 

•  renaming  the  files  so  information  contained  in  the  file  is  not  further  augmented 

•  resetting  file  contents 

•  verifying  that  logging  still  works 
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Rotating  log  files  allows  you  to  limit  the  volume  of  log  data  you  have  to  examine  at  any 
given  time.  It  also  allows  you  to  keep  log  files  open  for  a  limited  duration  so  that  damage 
is  bounded  if  an  active  log  file  is  compromised.  In  this  way,  you  create  a  collection  of  log 
files  that  contain  well-defined  time  intervals  of  recorded  data.  You  can  then  consolidate 
logs  from  different  systems  by  matching  time  intervals. 

This  will  help  you  gain  a  network-wide  perspective  on  the  activities.  To  perform  this 
consolidation,  you  will  likely  need  to  merge  log  files  from  different  systems  into  a  central 
log  file.  To  avoid  having  to  adjust  the  timestamps  used  in  each,  use  a  master  clock  system 
such  as  Timeserver,  NTP  (Network  Time  Protocol),  or  another  time  synchronization 
protocol  system. 

Back  up  and  archive  log  files.  Move  your  log  files  to  permanent  storage  or  capture  them  as 
part  of  your  regular  backup  procedure  if  you  want  to  retrieve  them  later  if  the  need  arises. 
Document  the  method  you  use  to  access  archived  log  files.  Create  backups  before  you 
execute  any  automated  tools  that  truncate  and  reset  the  log  files  so  that  minimal  logging 
data  is  lost. 

Encrypt  log  files.  We  recommend  encrypting  log  files  that  contain  sensitive  data  as  the  log 
data  is  being  recorded.  Protect  the  encryption  software  and  place  a  copy  of  your 
encryption  keys  on  a  floppy  disk  or  write-only  CD-ROM  in  a  secure  location  such  as  a 
safe  or  safety  deposit  box.  If  the  keys  are  lost,  the  log  files  cannot  be  used.  If  possible,  use 
public  key  encryption.  The  logs  can  be  encrypted  using  the  public  key  (which  can  be 
safely  stored  online)  and  the  corresponding  private  key  (stored  offline)  can  then  be  used  to 
decrypt  the  logs. 

Ensure  that  you  have  the  system  and  personnel  resources  necessary  to  analyze  logs  on  a 
regular  basis  and  on  demand  (i.e.,  in  some  cases,  daily,  and  as  alert  events  occur). 

Dispose  of  log  files.  Ensure  that  all  media  containing  log  file  data  are  disposed  of  in  a 
secure  manner  (e.g.,  shredding  hardcopy  output,  sanitizing  disks,  destroying  CD-ROMs), 


Policy  considerations 

Your  organization’s  security  policy  for  networked  systems  should  require  that  you 
document  a  management  plan  for  handling  log  files.  This  plan  should  include  what  to  log, 
when  and  why  to  log,  where  to  log,  and  who  is  responsible  for  all  aspects  of  the  plan. 

Other  information 

See  the  security  improvement  modules  Detecting  Signs  of  Intrusion  [Firth  97],  Preparing 
to  Detect  Signs  of  Intrusion  [Kochmar  98],  and  Responding  to  Intrusions 
[Kossakowski  99]  for  information  on  log  filtering,  analysis,  and  alerting  approaches. 

Where  to  find  updates 

The  latest  version  of  this  practice,  plus  implementation  details  for  selected  technologies,  is 
available  on  the  Web  at  URL 

http://www.cert.org/security-improvement/practices/p04Lhtml 
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Configure  computers  for  file  backups. 


Before  deploying  a  computer,  you  need  to  develop  a  file  backup  and  restoration  plan  and 
configure  the  computer  to  implement  that  plan. 


Why  this  is  important  File  backups  allow  you  to  restore  the  availability  and  integrity  of  information  resources 

following  security  breaches  and  accidents.  Without  a  backup,  you  may  be  unable  to 
restore  a  computer’s  data  after  system  failures  and  security  breaches. 


How  to  do  it  >  Develop  a  file  backup  and  restoration  plan. 

All  system  and  user  files  should  be  backed  up  on  a  regular  basis.  You  may  need  to  perform 
a  cost/benefit  analysis  to  help  you  decide  upon  the  balance  between  the  following:  the 
speed  of  the  backup  process,  the  amount  of  storage  needed  for  the  backed-up  files,  and  the 
effort  required  to  restore  one  or  all  files  from  backed-up  versions.  Develop  a  plan  that  is 
broad  enough  to  cover  all  the  workstations  and  servers  you  plan  to  deploy. 

If  you  have  regularly  created  cryptographic  checksums  for  all  files1  and  have  securely 
stored  these  checksums,  you  can  plan  to  restore  files  from  trusted  backups  against  which 
such  checksums  have  been  calculated. 

If  this  is  not  the  case,  you  need  to  restore  system,  executable,  and  binary  files  from  the 
original  distribution  media.  Then  you  must  reinstall  site-specific  modifications,  relevant 
patches,  and  bug-fixes.  You  need  to  ensure  that  these  modifications  do  not  introduce 
additional  defects  or  vulnerabilities.  Exercise  caution  when  restoring  user  files  from 
untrusted  backups  and  instruct  all  users  to  check  for  any  unexpected  changes  to  their 
restored  files. 

For  workstations,  there  are  two  common  approaches: 

•  Files  are  backed  up  locally  at  each  workstation,  often  by  the  user(s)  of  that  workstation. 
This  approach  has  the  advantage  of  not  requiring  that  protected  data  traverse  the 
network,  which  reduces  the  chances  of  it  being  monitored,  intercepted,  or  corrupted.  It 
has  the  disadvantages  of  requiring  additional  storage  devices  on  each  workstation, 
causing  increased  efforts  to  keep  the  many  backup  devices  and  media  secure,  and 
requiring  that  you  train  users  to  perform  the  backups. 


1 .  Refer  to  the  practice  “Keep  operating  systems  and  applications  software  up  to  date.” 
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•  Backups  are  centrally  administered,  with  data  copied  from  workstations  via  networks. 
Encryption  tools  such  as  SSH2  can  be  used  to  protect  data  passing  from  a  user 
workstation  to  a  central  backup  host. 

For  network  servers  that  provide  information  services  that  depend  on  automatic 
replication  mechanisms3,  a  third  approach  is  often  used.  The  authoritative  version  of  the 
information  content  of  the  server  is  created  and  maintained  on  a  secure  machine  that  is 
backed  up.  The  information  is  periodically  transferred  to  the  server  for  access  by  clients.  If 
the  server  is  compromised  and  its  content  damaged,  the  information  can  be  reloaded  from 
the  secure  system  maintaining  the  authoritative  version.  This  approach  is  typically  used 
for  public  servers,  such  as  DNS,  FTP,  and  Web  servers4,  because  the  content  changes  at 
more  predictable  intervals  than,  for  example,  a  server  that  provides  e-mail  and  file  sharing 
services  to  user  workstations  (which  requires  a  backup  approach  similar  to  those  described 
above  for  workstations). 

Determine  the  appropriate  medium  to  contain  your  backup  files  based  on  your 
requirements  for  speed  (for  both  reading  and  writing),  reliability,  and  storage  duration. 
Media  you  should  consider  include  magnetic  tape,  optical  disk,  and  CD-ROM. 

If  you  choose  central  administration  and  storage  of  backed-up  files,  ensure  that  the  backup 
tools  adequately  protect  data  confidentiality  and  integrity  as  it  travels  across  the  network 
from  the  host  to  the  backup  device.  We  recommend  that  you  use  encryption  technologies. 

The  plan  should  specify  that 

•  source  data  is  encrypted  before  being  transmitted  over  a  network  or  to  the  storage 
medium 

•  data  remains  encrypted  on  the  backup  storage  media 

•  storage  media  are  kept  in  a  physically  secure  facility  that  is  protected  from 
man-made  and  natural  disasters 

The  plan  should  be  designed  to  ensure  that  backups  are  performed  in  a  secure  manner  and 
that  the  contents  of  the  backups  remain  secure. 

>  Install  file  backup  tools . 

Select  file  backup  tools  to  allow  you  to  implement  your  backup  plan.  You  may  need  to  use 
third-party  software,  although  the  backup  capabilities  of  some  operating  systems  are  likely 
to  be  sufficient.  You  may  also  need  to  install  storage  devices,  either  centrally  or  on  each 
workstation  and  server,  to  store  the  backup  copies. 

The  tools  used  to  recover  backed-up  files  should  be  kept  offline,  rather  than  on  individual 
workstations  and  servers.  If  a  computer  has  been  compromised  and  you  need  to  recover  a 
file,  you  cannot  trust  the  integrity  of  any  of  the  tools  on  that  computer. 

>  Configure  the  backup  tools  and  initiate  the  scheduled  backups. 

Tool  configurations  need  to  reflect  your  backup  and  restoration  plan.  Configure  the  tools 
to  save  access  control  settings  along  with  file  contents,  if  that  feature  is  available. 


2.  Refer  to  the  implementation  “Installing,  configuring,  and  operating  the  secure  shell  (SSH)  on 
system  running  Solaris  2.x,"  available  at  http://www.cert.org/security-improvement/ 
implementations/i062.01  .html. 

3.  The  information  is  treated  as  though  it  resides  on  a  WORM  device  —  write  once,  read  many. 

4.  This  approach  is  elaborated  in  the  security  improvement  module  Securing  Public  Web  Servers 
[Kossakowski  00]. 
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Do  the  first  full  backup  just  before  deploying  the  computer,  and  then  confirm  that  you  can 
perform  a  full  restoration  from  that  backup  (refer  to  the  step  Test  the  ability  to  recover 
from  backups  below). 

>*  Confirm  that  the  scheduled  backups  are  being  performed  successfully. 

In  many  organizations,  file  backups  are  completely  automated,  so  system  administrators 
tend  to  forget  that  they  are  happening.  Therefore,  confirm  that  the  backup  procedures  for  a 
newly  deployed  workstation  are  actually  working. 

>  Test  the  ability :  to  recover  from  backups. 

For  many  system  administrators,  recovering  a  file  from  a  backup  is  an  uncommon  activity. 
This  step  assures  that  if  you  need  to  recover  a  file,  the  tools  and  procedures  will  work. 

Performing  this  test  periodically  will  help  you  to  discover  problems  with  the  backup 
procedures  so  you  can  correct  them  before  losing  data. 

Some  backup  restoration  software  does  not  accurately  recover  the  correct  file  protection 
and  file  ownership  controls.  Check  these  attributes  of  restored  files  to  ensure  they  are 
being  set  correctly. 

Periodically  test  to  ensure  that  you  can  perform  a  full  system  recovery  from  your  backups. 


Policy  considerations  Your  organization’s  security  policy  for  networked  systems  should 

•  require  the  creation  of  a  file  backup  and  recovery  plan 

•  inform  users  of  their  responsibilities  (if  any)  for  file  backup  and  recovery 


Other  information  Be  aware  that  file  backups  taken  from  compromised  machines  may  contain  damaged  files. 

services,  or  other  information  left  behind  by  an  intruder  (back  doors,  Trojan  horses). 
Exercise  caution  when  you  use  these  backups  to  restore  your  computers. 

Refer  to  the  practices  “Eliminate  all  means  of  intruder  access”  and  “Return  systems  to 
normal  operation”  in  the  security  improvement  module  Responding  to  Intrusions 
[Kossakowski  99]  for  a  discussion  of  approaches  to  consider  when  you  are  choosing 
backup  methods. 


Where  to  find  updates  The  latest  version  of  this  practice,  plus  implementation  details  for  selected  technologies,  i' 

available  on  the  Web  at  URL 

http://wwwxert.org/security-improvement/practices/p071.html 
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Protect  computers  from  viruses  and  similar 
programmed  threats. 


There  are  several  kinds  of  software  that  can  surreptitiously  breach  computer  security. 

These  can  occur  individually  or  in  combination  with  one  another.1 

•  virus:  a  code  fragment  (not  an  independent  program)  that  reproduces  by  attaching  to 
another  program.  It  may  damage  data  directly,  or  it  may  degrade  system  performance 
by  taking  over  system  resources,  which  are  then  not  available  to  authorized  users. 

•  worm:  an  independent  program  that  reproduces  by  copying  itself  from  one  system  to 
another,  usually  over  a  network.  Like  a  virus,  a  worm  may  damage  data  directly,  or  it 
may  degrade  system  performance  by  consuming  system  resources  and  even  shutting 
down  a  network. 

•  Trojan  horse:  an  independent  program  that  appears  to  perform  a  useful  function  but 
that  hides  another  unauthorized  program  inside  it.  When  an  authorized  user  performs 
the  apparent  function,  the  Trojan  horse  performs  the  unauthorized  function  as  well 
(often  usurping  the  privileges  of  the  user). 

You  should  configure  computers  to  take  countermeasures  against  these  threats.  In 

addition,  you  should  establish  policies  and  train  users  to  help  prevent  these  programmed 

threats  from  being  installed  on  their  workstations. 


Why  this  is  important  Programmed  threats  can  cause  significant  damage.  Your  confidential  information  can  be 

captured  and  transmitted,  critical  information  can  be  modified,  and  the  configuration  of  a 
computer  can  be  changed  to  permit  subsequent  unauthorized  access,  leading  to  intrusions. 
Services  provided  by  your  organization  can  be  interrupted  for  extended  periods  of  time, 
your  users  and  customers  may  lose  confidence  in  your  organization’s  ability  to  protect  its 
information,  and  you  can  experience  legal  ramifications  if  your  systems  are  used  as  launch 
points  for  broader  distribution  of  programmed  threat  software. 

Recovering  from  programmed  threats  can  be  expensive.  Installing  preventive  measures 
and  instituting  user  training  can  significantly  reduce  your  exposure  to  these  threats  at  a 
fraction  of  the  cost  it  would  take  to  recover  from  them. 


How  to  do  it  >*  Develop  a  plan  for  protecting  computers  from  viruses  and  similar  programmed  threats. 

The  plan  should  specify  how  much  responsibility  and  authority  users  and  system 
administrators  should  have  to  take  specific  actions  to  protect  their  computers  against 
viruses  and  similar  programmed  threats. 


1 .  Definitions  are  adapted  from  Deborah  Russell  and  G.  T.  Gangemi,  Sr.,  Computer  Security  Basics , 
O’Reilly  &  Associates,  Inc.,  1991. 
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In  the  plan,  describe  how  users  should  use  the  available  anti-virus  tools  for  workstations, 
and  describe  any  limitations  on  the  authority  of  users  to  download  and/or  install  new 
software. 


Policy  considerations 


►  Install  and  execute  appropriate  anti-virus  tools. 

Install  selected  anti-virus  tools  on  your  computers  following  a  clean  reboot  and  a  full 
system  check.  This  is  most  effective  if  you  perform  it  as  part  of  the  initial  installation  and 
configuration  of  the  operating  system. 

Regularly  check  for  viruses  using  the  online  version  of  tools. 

Store  copies  of  anti-virus  tools  offline,  in  a  secure  manner.  It  is  possible  that  a  new  virus 
could  modify  the  detection  and  eradication  software  to  prevent  its  own  detection. 

Periodically  use  off-line,  trusted  copies  of  the  tools  to  scan  your  systems,  particularly  after 
new  anti-virus  signatures  are  added  (see  the  last  step  below). 

Regularly  exercise  anti-virus  tools  on  all  network  servers  and  gateways.  This  can  be  done 
individually  or  from  a  central  administration  console. 

►  Train  users  in  virus  prevention  and  recognition  techniques 

Train  users  to  understand  how  viruses  and  other  programmed  threats  propagate  and  what 
they  can  do  to  help  prevent  further  propagation.  This  includes  training  them  to  use  virus 
detection  tools  on  software  obtained  from  public  sources  (such  as  shareware)  prior  to 
loading  and  executing  it  and  training  them  to  be  alert  to  the  possibility  of  such  threats  in 
email  attachments  and  downloaded  Web  content. 

Many  viruses  manifest  themselves  in  predictable  ways.  Train  users  to  recognize  virus 
symptoms,  report  them,  and  run  appropriate  virus  eradication  tools  (if  your  plan  permits 
them  to  use  these  tools). 

Keep  users  apprised  of  new  programmed  threats  and  related  intrusion  scenarios. 

>*  Routinely  check  for  and  update  programmed  threat  detection  tools  as  needed ,  especially 
when  new  threats  are  discovered. 

Many  anti-virus  tools  use  a  database  of  known  virus  characteristics  (signatures).  Vendors 
frequently  release  updated  versions  of  those  databases  on  a  weekly  or  monthly  basis. 
Ensure  that  your  computers  have  the  most  recent  versions.  Updating  your  anti-virus  tools 
using  vendor  updates  as  they  become  available  is  one  of  the  primary  methods  to  prevent 
virus  infections. 


Your  organization’s  workstation  acceptable  use  policy  or  security  policy  for  networked 
systems  should 

•  define  users’  authority  (or  lack  thereof)  to  download  and/or  install  software  on  the 
computer 

•  specify  who  has  the  responsibility  to  scan  for  viruses  and  eradicate  them  —  users  or 
system  administrators  —  and  where  to  scan  to  include  workstations,  servers,  and 
gateways 


2.  Note  that  this  step  is  primarily  applicable  to  workstations  rather  than  network  servers.  For 
servers,  the  administrator  is  responsible  for  virus  detection  and  eradication. 
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Where  to  find  updates 


•  prohibit  users  from  running  executable  files  that  they  have  received  as  e-mail 
attachments  or  downloaded  from  untrusted  sites.  If  such  a  file  needs  to  be  run,  it  should 
be  run  on  a  host  that  is  isolated  from  your  operational  systems.  The  host  should  not 
contain  sensitive  information,  and  the  file  should  be  run  through  virus  detection  tools. 
In  addition,  you  need  to  verify  the  file  originator. 


The  latest  version  of  this  practice,  plus  implementation  details  for  selected  technologies,  is 
available  on  the  Web  at  URL 

http://www.cert.org/security-improvement/practices/p033.html 
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Configure  computers  for  secure  remote 
administration. 


Administration  of  a  workstation  or  network  server  includes  updating  user  account 
information,  examining  the  logs,  installing  new  or  updated  software,  and  maintaining  an 
appropriate  configuration.  These  tasks  can  be  performed  locally  from  the  workstation  or 
server  console,  but  they  can  also  be  performed  remotely  from  a  separate  host  via  a 
network  connection. 

Although  local  administration  is  more  secure  (and  we  recommend  it  whenever  feasible), 
remote  administration  is  more  common,  particularly  when  servicing  a  large  number  of 
workstations  or  network  servers  (such  as  print  servers  and  file  servers).  When  performing 
remote  administration,  you  need  to  consider  the  security  of  the  administration  host,  the 
network,  and  the  workstation  or  server  being  administered. 


Why  this  is  important  Remote  administration  of  computers  is  increasingly  common  because  of  the  significant 

cost  benefits— many  tasks  can  be  automated,  and  the  administrator  does  not  have  to 
physically  visit  each  computer.  However,  remote  administration  tools  must  be  configured 
to  operate  securely. 

Although  the  normal  operational  state  of  your  computer  may  be  secure,  during  the 
performance  of  administrative  tasks,  your  computer  may  be  in  a  transient  vulnerable  state. 
This  is  especially  true  for  remote  administration  of  public  servers  that  have  been  placed 
outside  your  firewall,  because  this  requires  that  you  open  a  network  connection  through 
the  firewall.  Such  a  connection  may  be  vulnerable  to  some  forms  of  attack,  and  it  may 
open  the  door  to  anyone  on  the  Internet  being  able  to  “administer”  your  server.  The  result 
could  be  the  loss  of  confidentiality  or  integrity  of  information  resources  on  the  server,  an 
intruder  gaining  access  to  resources  on  your  internal  network,  or  an  intruder  being  able  to 
use  your  server  or  workstation  as  an  intermediate  host  for  attacks  on  other  internal  or 
external  hosts. 


How  to  do  it  >  Ensure  that  the  computer  accepts  administration  commands  only  from  an  authenticated 

administrator. 

Configure  the  computer  to  use  a  strong  method  to  authenticate  the  identity  of  the  user  who 
is  initiating  the  administrative  processes.  In  particular,  avoid  authentication  methods  that 
require  the  transmission  of  a  password  in  clear  text,  unless  it  is  a  one-time  password. 
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>  Ensure  that  the  computer  allows  administration  from  only  an  authenticated  host. 

Authenticate  the  host  in  a  manner  that  does  not  depend  on  network-resolved  information 
such  as  IP  addresses  or  DNS  names,  because  intruders  can  falsify  such  information  within 
packets  sent  to  computers  being  administered.  We  recommend  the  use  of  public  key 
authentication  using  a  tool  such  as  secure  shell  (SSH).1 

See  also  the  module  Securing  Public  Web  Servers  [Kossakowski  00],  specifically  the 
practice  “Configure  the  Web  server  to  use  authentication  and  encryption  technologies, 
where  required.”  This  practice  briefly  covers  SSL  (Secure  Socket  Layer),  S/HTTP  (Secure 
HTTP),  and  SET  (Secure  Electronic  Transaction)  for  use  with  public  Web  servers. 

>  Ensure  that  all  administration  tasks  operate  at  the  minimum  necessary  privilege  level. 

Administration  tasks  sometimes  require  increased  privilege  levels.  Take  care  to  raise 
privilege  levels  only  as  needed. 

Consider  separation  of  duties  among  administrators  which  will  allow  you  to  assign 
privilege  levels  as  needed.  This  eliminates  the  risk  of  one  administrator  becoming  a  single 
point  of  vulnerability. 

>*  Ensure  that  confidential  information  cannot  be  intercepted,  read,  or  changed  by  intruders. 

This  includes  administration  commands  and  system  configuration  information. 

Methods  such  as  encryption  help  to  ensure  that  network  packets  travelling  between  the 
administrator’s  host  machine  and  the  computer  being  administered  would  not,  if 
intercepted,  provide  sensitive  information  or  permit  system  commands  to  be  altered.  Such 
actions  could  allow  subsequent  access  to  either  the  computer  or  your  organization’s 
internal  network.  We  recommend  the  use  of  SSH1  or  an  equivalent  encryption  tool. 

Use  a  movable  storage  medium  to  transfer  information  from  the  authoritative  copy  to 
public  servers  outside  your  firewall. 

For  some  network  servers,  particularly  those  providing  public  services  such  as  WWW,  it  is 
common  to  develop  the  information  content  of  those  services  on  a  different  host  machine. 
The  authoritative  version  of  that  content  is  maintained  (and  backed  up)  on  that  other 
machine,  and  then  transferred  to  the  public  server  at  appropriate  intervals.  The  transfer  can 
be  performed  by  using  a  movable  storage  medium.  This  could  include  a  writable  CD- 
ROM,  diskette,  hard  disk  cartridge,  or  tape.  Since  this  procedure  does  not  require  a 
network  connection  through  your  firewall,  it  is  more  secure. 

If  a  network  connection  is  required,  use  an  encrypted,  authenticated  VPN  connection. 

During  the  transfer,  you  may  need  to  stop  or  disable  your  server.  Some  servers  can  be 
configured  to  continue  operating  and  to  send  a  “Service  temporarily  unavailable”  message 
in  response  to  all  requests. 

Do  not  use  a  transfer  method  that  mounts  a  file  system  from  a  host  inside  the  firewall  on  a 
public  server  host  (such  as  a  Web  server)  using  NFS.  There  are  inherent  problems  in  the 
NFS  protocol  that  could  make  that  internal  host  vulnerable  to  attack. 


1.  Refer  to  the  implementation  “Installing,  configuring,  and  operating  the  secure  shell  (SSH)  on 
systems  running  Solaris  2.x”  available  at  http://www.cert.org/security-improvement/ 
implementations/i062.01.html. 
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Correspondingly,  do  not  use  an  NFS-based  transfer  method  in  the  opposite  direction  (from 
public  server  to  internal  host).  This  could  result  in  making  your  public  server  vulnerable  to 
attack. 

>  Use  a  secure  method  for  inspecting  all  log  files. 

If  you  choose  to  inspect  the  computer  log  files 

•  on  a  host  other  than  the  computer  that  generated  the  logs,  use  a  secure  method  for 
transferring  these  logs.  Movable  storage  media  and  file  encryption  are  two  suitable 
methods. 

•  by  remotely  accessing  the  computer  from  another  host,  use  appropriate  authentication 
and  encryption  technologies  as  described  above 

•  by  remotely  accessing  a  central  log  host  that  contains  all  log  files,  use  appropriate 
authentication  and  encryption  technologies  as  described  above 

>  After  making  any  changes  in  a  computer's  configuration  or  in  its  information  content , 
create  new '  cryptographic  checksums  or  other  integrity-checking  baseline  information  for 
your  server. 

See  the  modules  Detecting  Signs  of  Intrusion  [Firth  97]  and  Preparing  to  Detect  Signs  of 
Intrusion  [Kochmar  98]  for  additional  information  on  the  role  of  checking  the  integrity  of 
baseline  information  in  support  of  intrusion  detection. 


Policy  considerations  Your  organization’s  security  policy  for  networked  systems  should 

•  require  the  use  of  secure  procedures  for  administration  of  network  servers  and 
workstations 

•  specify  the  circumstances  under  which  third  parties  (vendors,  service  providers)  are 
permitted  to  remotely  administer  your  systems  and  how  such  administration  is  to  be 
conducted.2 


Where  to  find  updates  The  latest  version  of  this  practice,  plus  implementation  details  for  selected  technologies,  is 

available  on  the  Web  at  URL 

http://www.cert.org/security-improvenient/practices/p073.html 


2.  Refer  to  the  module  Security :  of  Information  Technology  Service  Contracts  [Allen  98]. 
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Allow  only  appropriate  physical  access  to  computers. 


In  addition  to  the  steps  you  take  to  prevent  inappropriate  electronic  access  to  a  computer, 
you  should  also  strive  to  allow  only  appropriate  physical  access.  What  this  means  can  vary 
depending  on  the  locations  of  computers — whether  they  are  in  locked  offices  or  in  open- 
plan  space,  for  example. 

Physical  access  also  includes  activities  such  as  installing  or  removing  hardware. 


Why  this  is  important  If  unauthorized  persons  can  physically  access  a  computer,  the  integrity  of  that  system  is  at 

considerable  risk.  If  a  system  is  connected  to  internal  networks,  then  intruders  can  access 
resources  in  a  way  that  bypasses  all  of  your  network  perimeter  defenses. 

To  preserve  the  confidentiality  and  availability  of  data,  you  must  prevent  the  computer  and 
its  storage  media  from  being  removed  from  the  facility  by  unauthorized  persons. 

If  new  hardware,  such  as  a  modem,  is  installed  it  may  create  new  electronic  access  paths 
to  the  computer  and  make  your  network  available  to  intruders. 


How  to  do  it  >  Prevent  installation  of  unauthorized  hardware  and  modification  of  authorized  hardware . 

Installation  of  new  hardware  can  lead  to  security  problems  in  several  ways: 

•  Installing  a  modem  allows  a  direct  connection  from  the  computer  to  the  public 
telephone  network,  which  may  then  permit  electronic  access  into  your  network  from 
anywhere  in  the  world,  bypassing  your  perimeter  defenses. 

•  Installing  a  removable-media  storage  device  or  printer  makes  it  easy  to  copy 
information  and  carry  it  away  from  your  site. 

•  Installing  a  boot  device  that  precedes  the  authorized  device  in  the  boot  sequence  alio  vs  s 
the  computer  to  be  restarted  in  a  configuration  that  bypasses  your  security  precautions 

You  should  lock  the  computer  case,  if  possible.  This  may  require  third-party  locking 
devices  such  as  keys,  cables,  or  racks.  If  a  key  is  used,  ensure  that  the  key  is  protected.  \  el 
still  accessible  to  authorized  users.  Make  a  backup  key  and  protect  it  in  a  secure  offsite 
location. 

You  may  also  want  to  remove  or  disable  the  external  connectors  on  the  computer. 
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>  Deploy  the  computer  in  a  secure  facility . 

Deploying  the  computer  in  a  secure  facility  helps  to  prevent  unauthorized  access  to  the 
computer,  theft,  and  destruction.  Methods  of  secure  deployment  may  include  using 
surveillance  cameras  or  placing  the  computer  in  a  locked  room  that  uses  controlled 
physical  or  electronic  access  which  is  recorded.  Pay  special  attention  to  controlling  the 
access  of  vendors,  contractors,  and  other  visitors. 

As  a  general  rule,  do  not  deploy  network  servers  in  an  individual's  office. 

Locate  the  computer  so  unauthorized  viewing  of  the  monitor  and  keyboard  cannot  occur. 

Provide  additional  shielding  against  electronic  eavesdropping  or  interference,  if  required. 

Secure  the  network  wiring  and  other  network  connection  components. 

For  security  purposes,  ensure  that  the  network  cabling  is  not  placed  in  a  physical  location 
where  it  can  be  easily  accessed.  Note  that  this  requires  you  to  trade  the  convenience  of 
access  for  network  maintenance  for  greater  security. 


Policy  considerations  Your  organization’s  security  policy  for  networked  systems  should 

•  specify  who  is  or  is  not  allowed  to  install  new  hardware  or  modify  existing  hardware  in 
a  computer 

•  specify  the  circumstances  under  which  users  may  or  may  not  use  storage  devices  with 
removable  media 

•  specify  the  circumstances  under  which  users  may  take  storage  media  or  printed 
information  away  from  your  site 

•  require  that  network  servers  be  deployed  in  physically  secure  locations 

•  specify  the  circumstances  under  which  third  parties  (vendors,  service  providers)  are 
permitted  to  physically  access  your  systems  and  how  such  access  is  to  occur. 


Other  information  If  you  need  to  protect  against  unauthorized  monitoring,  eavesdropping,  or  interference  of 

electronic  emanations  coming  from  your  computing  equipment,  you  may  need  to  consider 
physical  protection  technologies  such  as  TEMPEST  (Transient  Electromagnetic  Pulse 
Emanation  Standard).  Refer  to  http://www.dewsite.eom/fyeo/tempest.html#Government 
and  http://www.eskimo.com7~joelm/tempest.html  for  further  information  on  TEMPEST. 


Where  to  find  updates  The  latest  version  of  this  practice,  plus  implementation  details  for  selected  technologies,  is 

available  on  the  Web  at  URL 

http://www.cert.org/security-improvement/practices/p074.html 


1.  Refer  to  the  module  Security'  of  Information  Technology  Service  Contracts  [Allen  98]. 
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The  practices  recommended  here  are  designed  to  help  you  configure  and  deploy  network  servers  that  satisfy 
your  organization’s  security  requirements.  The  practices  may  also  be  useful  in  examining  the  configuration  of 
previously  deployed  servers.  _ 
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